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
Author: Joel Darnauer
Date: Tue, 01 Sep 1992 02:41
Date: Tue, 01 Sep 1992 02:41
68 lines
3435 bytes
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
Author: Kumar Venkat
Date: Tue, 01 Sep 1992 20:29
Date: Tue, 01 Sep 1992 20:29
50 lines
2308 bytes
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