The multisite sub-group believes that any STIL.4 program should be able to be run as multisite (if the software implementation supports multisite). However, we recognize there are often additional considerations in making a successful multisite program.

This memo limits the scope of the multi-site sub-group of the STIL.4 working group. Issues identified here will be further considered for their relevence to standardization. However, many of the issues on this list may very well be dropped after further consideration. It is our intention that issues not identified here do not warrant consideration.

We believe that any multi-site standard must address issues numbers 1 and 2. The other issues have arisen in our conversations as having some impact to some multi-site implementations, but we haven't yet evaluated the need or feasibility of their standarization.

We would appreciate your feedback as to the relative importance of the issues on this list, as well as any additional issues that you feel belongs on this list.

1. Sequencing. When divergence happens (such as one site failing where another passes), what is the precise sequence of subsequent testing? On most modern testers, the parallel processing of the execution sequencing is limited by some shared resource (such as the tester controller) so that it is not possible to simultaneously execute different sites at different FlowNodes. Instead, testing is suspended on one side of the branching as testing continues on the other side. This bifurcation is limited only by the complexity of the test flow, and the number of active test sites.
   There is the "pass-priority" concept (where the failing site is disabled while the passing site continues testing until done, at which point the failing site resumes), and "fail-priority" (this can be generalized to any number of output ports). There has been the suggestion that there may be a need for this pass-priority versus fail-priority preference might be required to be made at each FlowNode (but probably with a default for any FlowNode that doesn't explicitly indicate).
   • There is also the "reconvergence" question (after sites diverge - can they reconverge? if so, the sequencing can't be strictly pass-priority or fail-priority).
   • Also, how are there sequencing issues when there are loops in the flow? (This is relevent to reconvergence.)
2. Disabling/re-enabling. When a site is temporarily disabled (such as if it fails a test where another sites passes), how is that site disabled? Can the user specify the precise operations for disabling the site (such as powering it down, or disconnecting/isolating certain pins - while reconnecting others). Some devices need at least a clock while they are disabled. While testing is occuring on other sites, what stimulus can the disabled site receive?
   Once it is time to re-enable the site, what is the precise operations that achieve this? (May need to powerup the device, or run a match-mode pattern).
   We'll likely need to offer the test-programmer "hooks" to be able to do whatever they want (but these would not be required).
3. Loadboard instrumentation. In some cases, testing requires some special loadboard (or other user-defined) circuitry that interacts with the DUTs. These may require some special programming (based on what sites are enabled or disabled).
   This loadboard instrumentation could be a shared resource that is accessible to sites simultaneously (such as a power supply to bias some loads), or a shared resource that must be multiplexed to each site independently, or their could be an instrument per-site.
   Note: we believe that the tester vendor's software should handle any issues associated with utilizing its resources (such as whether they can be used in parallel or must be serialized).
4. Datalogging. During multisite execution can the datalog stream mix records from different sites? Can a datalog record report results for multiple sites simultaneously (e.g. could a datalog record indicate that sites 1,2,4 all passed a functional test? - the answer is "yes" for STDF - but are people concerned with other datalog formats) If so, then the datalog stream will look significantly different than it would if each of the sites were tested independently (serially).
   Do we need to have an answer to compatibility with existing non-multisite datalog formats? ("yes" might imply that datalogging for different sites goes into different files - one file per site).
5. Binning. This often comes up during multisite discussions, but many of the binning issues will be addressed in the main STIL.4 - or under the Sequencing bullet above.
   Perhaps one issue is when/how are binning results communicated to the handler? Does this happen as soon as the results are known to the software? Or are these queued up and sent to the handler as a collection of results?
6. Continuity failure kickout. In DRAM multisite testing, it is common to run some quick tests once all sites are socketed. If any DUT fails, then it is unsocketed, discarded, and a new DUT is socketed. Therefore such a failing DUT doesn't occupy a site during the long pattern tests. Unfortunately, we don't have anyone in the sub-group who has direct experience in this matter.
   Also, in logic testing some people have the handler reseat DUTs that fail a continity test (or remain seated while other sites are binned - so they are retested).
7. Entrance Points. These will part of the main STIL.4 specification - initial thoughts include the following:
   User defined load (prior to Start). This would include operator interface items such as the Test Engr. flow variable passage. etc.
   the Start node (such as for power-up).
   the main flow (this is what normally does the real testing)
   the Finish of the flow (for power-down).
   Unload. This would be used for relay control etc. at the end of the test.
   Additionally, multisite may have some additional requirements (such as for disabling and re-enabling the DUT).
8. Loadboard connection syntax 1450 doesn't have a construct for defining the mapping from Signals to tester resource (but this may be part of the 1450.3 charter). Should we consider adding a multisite capable mapping? Or at least participate in 1450.3 enought to see that they (1450.3) do it in a way we like?
9. Prematch and postmatch Conditional pattern issues with lockstep operation. Some approaches to simple match loops such as having "prematch" and "postmatch" fragments that get spliced so that each site matches independently while others do either pre or post. We may want to consider adding such blocks to the STIL Pattern language.
10. Isolation This is touched on in issue #2 (disabling/re-enabling), but maybe this warrants further consideration. For example, we could provide a formal syntax that indicates what the DUT's isolation requirements are (isolation form power-supply changes, isolations from clocks, isolations for signal pin toggling, etc.)