From: owner-stds-1450-4@majordomo.ieee.org on behalf of Gordon Robinson [Gordon_Robinson@3mts.com] Sent: Wednesday, April 17, 2002 3:45 PM To: 'Micek Tom-ra1370'; 'DOWDING,DAVE (A-Loveland,ex1)'; Gordon Robinson; stds-1450-4@majordomo.ieee.org Subject: RE: stds-1450.4: stds-1450.4 Multi-site STIL Tom: I was definitely speaking in a tester vendor role. I've seen and heard too many horror stories of subtle mult-site program bugs when these were left to the users to want to see any more. For what we standardize I'd like the flow to be what each site is supposed to see. I fully expect implementations to add some extra pieces, but they're unlikely to be portable. Gordon -----Original Message----- From: Micek Tom-ra1370 [mailto:Tom.Micek@motorola.com] Sent: Wednesday, April 17, 2002 3:32 PM To: 'DOWDING,DAVE (A-Loveland,ex1)'; 'Gordon Robinson'; Micek Tom-ra1370; stds-1450-4@majordomo.ieee.org Subject: RE: stds-1450.4: stds-1450.4 Multi-site STIL Dave, Gordon & all, This is one of those things which can be argued both ways. On one hand we would like to have a STIL language that is portable from tester to tester and therefore should have the ability to control how the multi-site w/multi-sort path is handled. If we let the implementation up to the tester vendor then the portability is in question. On the other hand it would be nice to let the tester vendor handle the path issues as you mention. Prior to Friday's meeting I will try to get the tester vendor's take on this topic for their opinion. Regards, Tom. -----Original Message----- From: DOWDING,DAVE (A-Loveland,ex1) [mailto:dave_dowding@agilent.com] Sent: Monday, April 15, 2002 5:52 PM To: 'Gordon Robinson'; 'Micek Tom-ra1370'; stds-1450-4@majordomo.ieee.org Subject: RE: stds-1450.4: stds-1450.4 Multi-site STIL Greetings, Tom's case represents a difficult set of problems. First is the case of various paths through the test program as a device fails and passes through different "down grading" flow nodes, i.e. a test methodology intent to find subset of function or performance that is shipable. The second is testing multiple devices in "parallel", or some approximation of that method. I believe that the requirement to "annotate" the path taken through the test flow nodes is reasonable if not absolutely necessary. It is not clear to me, at this time, if we need to build the mechanisms to provide this function, or if it should be, as Gordon suggested, an extention. I have thought of one approach where flow nodes have a "token" of the node's id that could be added to a run-time list. Unique node ids are note easy to accomplish, but not impossible. Secondly, I believe that it is not the P1450.4 charter to define implementation. I see multi-site as an implementation. My reasoning stems from part of Gordon's example, namely, the control of the single or multiple site is going to be implemented very differently on a shared control tester versus a "per-pin" control one. In addition, I believe that just as Gordon pointed out, there are specific tests that may defy parallel testing. Match mode type testing is handled well in multi-site on one tester and not on another. This should not cause us to avoid having Match mode tests in our flow. It is simply a question of how a given tester implements that type of test. For this second case, one possibility is for P1450.4 to state the standard "language" or data structure for test flow of a single site and allow the ATE vendor to use that in a multi-site situation to their best fit. Dave Dowding -----Original Message----- From: Gordon Robinson [mailto:Gordon_Robinson@3mts.com] Sent: Monday, April 15, 2002 2:27 PM To: 'Micek Tom-ra1370'; 'dave_dowding@agilent.com'; stds-1450-4@majordomo.ieee.org Subject: RE: stds-1450.4: stds-1450.4 Multi-site STIL I've got a belief that the test program flow information says what's got to happen on a single site. All sites have to obey that flow, by whatever techniques the test system uses to make that happen. The test engineer should not have to get involved with specifying "how" the test syste does that. Usually. I'd expect each test system to implement a few "extensions" for how any local "tricks of the trade" can be controlled. Let me give an example of such a "trick of the trade" from a former company. Testers with a single sequencer can't run patterns with match on more than one site at a time, because the sites may start in different states. But it may be the case that a process will produce devices that do all come up in the same state. Or the test may be positioned after another that leaves all sites in a common state. So a multisite strategy could allow "run in parallel, expecting to pass if they all start the same, and to get a match timeout if they start differently. In the event of the match timeout, run sites one at a time." With such an option in how things are run, there was obviously a setting to force whether to try that method or not. Does anyone else support my view? Or disagree? Gordon -----Original Message----- From: Micek Tom-ra1370 [mailto:Tom.Micek@motorola.com] Sent: Monday, April 15, 2002 11:55 AM To: 'dave_dowding@agilent.com'; stds-1450-4@majordomo.ieee.org Subject: stds-1450.4: stds-1450.4 Multi-site STIL Dave & 1450.4 team, I would like put the attached into the STIL.4 queue regarding multi-site testing with multi path flow. We will be using STIL for scan & bist testing multi-DUTs to the limits of the tester, power supplies and the mechanical limitations. I would be glad to discuss this further with the group when time permits on this topic. Regards, Tom. -- Tom Micek Dept: RU621 Phone: (512) 895-7478 Motorola Mail Stop: OE21 Fax: (512) 895-3701 6501 William Cannon Drive West email: tom.micek@motorola.com Austin, Tx. 78735-8598