Let me comment on
some of the multisite issues, with the
danger that this
may add to people's confusion with a difficult topic
before it resolves
things.
I try to take a
couple of extremely strong stances about multisite:
- When testing
multisite, each device ends up in the same bin as it does when tested
alone
- When
testing multiste, each device produces the same datalog results as when
tested alone
[DVO] This could be interpretted in two ways. I agree
that the information in the datalog should be the same. However, one
site's datalog information may be interspersed with another's. I'm told
that's how STDF is.
- When
testing multisite, each device experiences the same set of test steps as
when tested alone
[DVO] Does the disabling/enabling of a site count as
a "test step?"
- The user
specifies what happens for testing the device as if testing it alone, and
very little else for multisite beyond load board connections
[DVO] This is a
fundemental goal that (I think) we all agree with. However, in
practice, I've seen that many test-engineers prefer some additional control
over some of the multisite issues - generally with an eye toward increased
throughput or due to considerations relative to the device. The way I
reconcile this is by agreeing with your statement, but saying that
additional optional syntax may be added to the STIL file by a test
engineer to address multisite
issues.
I regard it as OK
for a device to experience different time delays "between steps" when being
tested multisite.
Different stimulus
of any form gets me concerned.
I think
we're in trouble when a device has to go through new power-up sequences or be
reinitialized whenever it gets enabled after being disabled.
[DVO] I'm not a
test-engineer, but different devices have different requirements. I'm
told that some must keep a clock going (or else they burn up!) and that some
of these "keep-alive" patterns require support from the pattern-sequencer, and
many testers can't maintain this "keep-alive" pattern on some sites, while
executing the AC tests on other sites. So, the alternative chosen is to
power-down these devices for the periods in which they are disabled. Perhaps
such devices aren't great candidates for multisite
testing.
There are quite a
few general approaches to how multisite testing is
performed.
- Have a complete
set of tester resources, processor, sequencer, pins, instruments for each
site. The system is a collection of single site testers. This method is used
for some memory testers, and handles issues like match very well. All sites
progress through the flow independently at their own natural
pace.
[DVO] This would make our job easy! Are there
many testers like this? This is the opposite of the multisite DRAM
tester I was introduced to several years ago. That system had just a
single sequencer and single set of programmable levels which were shared
across all sites.
- Have a single
thread of activity and run all sites "lockstep". This is the common method
where the system has (or behaves like) a single digital sequencer. The
system has to choose which step in the flow to run next, and enable and
disable sites as it does so. When in trouble, run the sites through a step
one at a time. This is the style that Tom's note seems to be assuming,
particualrly when discussing "pass-priority" and
"fail-priority".
- In that model
I've heard plenty of advocates for each priority strategy. Let the user
choose whic they believe gives them fewest problems.
- Have a thread for
each site within a test process, allow each to run "sort-of" independently,
and to come together and run a step lockstep style where
appropriate.
[DVO] We probably want a
programming model that makes few assumptions and could be implemented with any
of the above approaches. The 2nd bullet is the one I'm most familiar with -
and it is the one the raised in issue #2 (disabling/re-enabling) of the
working list.
The hard
issues of multisite occur when the test program has to deal with issues that
challenge its model.
- Running sites
independently, but there are some expensive instruments that can't be
dedicated, and so sites need to be scheduled for whan they can use
them.
- Conditional
pattern issues with lockstep operation. I've seen 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.
- Making sure that
switching matrices are used correctly when they can switch things to several
sites.
- Making sure
that activities on one site really don't disturb others. E.g. if a DPS
channel is shared between sites, is it OK for an enabled site to change the
setting while another site is disabled.
[DVO] Let's call this
"isolation". Should 1450.4 make explicit assumptions about a tester's
capabilities in this regard?
- Loadboard
instrumentation the test system doesn't even realize is
instrumentation!
[DVO] Bullets #1, #3, and maybe #4 are issues that I think
are owned by the ATE vendor and don't require much consideration from us. It
is the ATE vendor's responsibility to execute STIL.4 on their tester and if
their tester has limitiations such as those listed, then they should be
responsible for resolve them. I don't think STIL.4 should need any syntax to
address those issues.
I don't view datalogs as a a simple
stream, but as a separate stream for each site. How thats treated visually is
a UI design issue.
I hope I've
stirred up a few things!
[DVO] From reading your email, I think the following are
issues we should consider adding to the working list (remembering that the
list is not of things we must address, but is of things we should consider
addressing):
- Syntax for the loadboard
connections. 1450 doesn't have a construct for defining the mapping
from Signals to tester resources - but I think this is in the 1450.3
charter. Should we consider adding a multisite capable mapping? or at least
participate in 1450.3 enough to see that they do it in a way we
like?
- prematch and postmatch for match
mode.
- Isolation assumptions/requirements.
This is touched on in working list issue #2 (disabling/re-enabling), but
maybe this warrants further
consideration.
Gordon