• For the testing throughput, the user also wants to control the test flow is either PASS first or FAIL first. This control is often based on the DUT and/or test type.

I'll jump in with a couple of related questions and issues:

1. Aside from the match-mode and reconvergence issues already raised, I think there are other semantic issues that could be associated with multisite testing: When branching occurs and testing continues on some sites, there is the question of what states the other sites should be in. Is it ok for them to be stimulated by the vectors being applied to the active sites? Should/must clocking continue? Can they be subjected to power supply voltage fluctuations that may be applied to the active sites? Is it necessary to "rematch" the devices before testing continues? I think we would need to consider questions such as these if we want STIL.4 to be "multisite-ready".
2. Other forms of concurrency: Multisite testing is one form of concurrency. I believe others that are also used to some degree in modern ATE. In mixed-signal testing, it is common for some tests to occur independently but concurrently with other tests. In cores testing, there is a desire to be able to test multiple cores simultaneously. Although we can easily claim these issues are beyond the scope of 1450.4, we seem to be headed toward a node based (declarative) form of test description. It would be relatively easy to add a "fork" and "join" capability to such a description. Also, it might not be too great of a stretch for testers that have multiple sequencers to be able efficiently implement to such a model. I should note that it is possible to implement to a fork/join model even when concurrency is not possible, since most such models say only that certain operations may run concurrently, not that they must. This may be a discussion for another day, but I thought I'd raise it now.

Don Organ




-----Original Message-----
From: owner-stds-1450-4@majordomo.ieee.org
[mailto:owner-stds-1450-4@majordomo.ieee.org]On Behalf Of Gordon
Robinson
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