From: Don Organ [don.organ@inovys.com]
Sent: Friday, June 14, 2002 1:36 PM
To: Tom Micek
Subject: Multisite issues.
Tom,
Here's the list of "issues" for multisite testing - as we discussed on our call 6/11/2002. Please let me know of what I'm missing and of any corrections.
  1. Sequencing. When divergence happens (such as one site failing where another passes), what is the precise sequence of subsequent testing? 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". There has been the suggestion that this pass-priority versus fail-priority decision might need to be made at each FlowNode. 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)
  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 failing 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).
  3. Loadboard instrumentation. In some cases, testing requires some special loadboard circuitry that interacts with the DUTs. These may require some special programming (based on what sites are enabled or disabled).
  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?) If so, then the datalog stream will look significantly different than it would if each of the sites were tested independently (serially).
  5. Binning. This often comes up during multisite discussions, but I haven't been able to identify any binning issues for multisite beyond the STIL.4 binning issues.
  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.
 
-DVO-
 
 
 
-----------------------------------------------------------------
Don Organ                      Inovys Corporation
(925) 924-9110 x122
-----------------------------------------------------------------