🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.lsi.testing
2 messages
2 total messages Started by Joel Darnauer Tue, 01 Sep 1992 02:41
Re: to test or not to test
#46
Author: Joel Darnauer
Date: Tue, 01 Sep 1992 02:41
68 lines
3435 bytes
I believe there must be someone out there that has extended
the qualitative anaylsis of the situation to a more
quantitative analysis.  It is relatively easy to look past
the system you are designing to the system that it will be
incorporated into to get an idea what the cost of assembly
defects is.


BENEFITS OF TESTING 
-------------------
Most testing significantly reduces the risk of failure.  Take
for example the following scenario: We are manufacturing a
product, say a workstation, from N:=100 ICs which all have
identical and independent probability of being defect-free,
y:=99.9%.  (1000ppms is a bit low for most ICs, but still
pretty good).

With no assembly errors, the yield of the assembly will be
about Y:=y^N=90%, which for large N can be very small indeed.
By not testing the devices before assembly, we are taking the
risk that the effort expended in the assembly operation will
be wasted.  If the cost of the assembly operation and parts
is C:=$200 ($100 labor plus parts at $1 each), then risk
involved in not testing the components is R:=C(1-Y) or $20.
Let us assume that diagnosis and rework are cost well over
$20, so we just add %10(:=(1-Y)/Y) to our price and go to bed
dreaming of the millions of dollars we could save if we, or
rather our suppliers, had better yield.


WHO SHOULD BEAR THE BURDEN OF TESTING?
--------------------------------------
This brings up a crucial point.  In the bad old-days, or so I
am told, the industry had to rely on incoming inspection to
keep yields high.  This created a lot of problems for
manufacturers, because each had to invest in seperate test
equiptment for each component in thier assembly.  It far more
logical (i.e. economical) for the supplier to guarantee his
part before shipping it out, because he has the expertise to
perform the tests and can spread the cost over millions sold
rather than a few thousand bought.  Plus, if you don't test,
your customers will eventually migrate to more reliable
suppliers, unless they share a similar disinterest in guaranteeing
their product.


PRICE OF TESTING
----------------
Though I believe little is known about the cost of test
coverage I think it is fair to say that 10% of the faults in
the fault model- universe in question probably account for
90% of the failures.  This is the only reason why I can think
that functional test can compete with ATPG.  Since finding a
test-set with %100 fault-coverage for even the simplest types
of fault models is NP-complete, it is usually imposible to
guarantee 100% yield.  What I want to know is: what is the
marginal cost/benefit of testing?  I.e. how much
computational work does it take to "add" a vector to a
non-redundant test set, and how many more real defects is
that vector likely to detect?

What seems to be lacking at this point is a rigorous model of
where exactly the cost of test begins to exceede the benefits
of test.  The question posed should not be "To Test or Not
to Test?"  but "How Much Testing is Needed?"

Joel Darnauer
joel@ce.ucsc.edu
Re: to test or not to test
#47
Author: Kumar Venkat
Date: Tue, 01 Sep 1992 20:29
50 lines
2308 bytes

For those who see the light and decide that testing
is necessary, there are still a number of questions
regarding WHAT to test and HOW MUCH to test. This
is from a design engineer's point of view.

The majority of companies/managers/engineers that
believe in testing simply invest in an ATPG tool
that generates tests for single stuck-at faults. There is usually very
little consideration given to
real defect modes in real chips and how these defects map into various
fault models (stuck-ats,
bridging faults, transistor gate open, etc.). 

It is difficult to know exactly what defect modes
to test for (and what fault models to use in order
to reasonably cover these defects). Even if one
decides on fault models somehow, getting proven ATPG
tools that can cover those faults directly or
indirectly is quite difficult. Even if appropriate
ATPG tools can be found, getting the ASIC vendor
to accept "non-standard" test vectors (such as
delay fault testing using scan, or IDDQ testing)
is a difficult task in general.

Thus, most people settle for some kind of scan
structure (full/partial) and a stuck-at fault
model, because that is the easiest thing to do.
Fault coverage in the high 90's makes people feel
good about what they have done, especially when
they hear from the foundry that 60% of the chips
from a lot didn't pass the scan tests.

Then comes the question of how much to test. Design-
for-test typically comes at a price (area,timing),
but DFT is usually necessary to keep fault coverage
high. How much fault coverage is good enough,
especially when one uses a stuck-at model and does
not know what real defects are being covered ? Note
that process yield is also unknown most of the time.




-Kumar Venkat

 Silicon Graphics, Inc.
 (415) 390-5320
 kumarv@sgi.com
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads