How do you define DFT?
What is DFT? Many designers just say it’s a pain in the ass. But TMAG has a more accurate description in mind. And they’d like to know if you agree. I blogged a few days ago about the 4/1 general meeting of TMAG (Testability Management Action Group). Well, the ‘Beyond DFT’ committee of said organization discussed/debated some basic definitions (presumably at this last meeting) as a basis of understanding. I would think it’s important that the members of any initiative all be reading from the same page. Here are the definitions they’ve put forward:
Testability is a property of a circuit that enables one to test it easily, or in some cases to test it at all, by being able to control and observe signal nodes that are buried within the circuit.
Design for Testability (DFT) is a methodology incorporated in the design of electronic circuits which takes into consideration the post-design testing phase, and which attempts to reduce the effort and cost of testing.
Structured Design for Test (Structured DFT) is a design technique, usually for ICs, which enables tests to be created automatically or algorithmically. One example of is the design of an IC with a scan structure that enables test for structural faults using a predefined test methodology. While the test may be long, it can be generated without test engineering involvement and test patterns created by computer programs can ensure nearly 100% fault detection of certain fault types.
Built-In Self-Test (BIST) is a method of design – generally for ICs – whereby the mission circuit tests itself. Though this is seldom performed strictly without additional circuitry, if the entire circuitry performing the test is contained within an IC, we call it self-test, in situ test, or built-in self-test.
Built-In Test (BIT) is similar to BIST in that it performs test of the circuit it resides in, but it is generally used at board and system levels and often uses extra hardware, software, and/or firmware to implement the test. When the added circuitry is substantial, it may be called embedded test. If BIT is implemented in software, it is called BIT software.
So what do you think? Send your opinions to LouisUngar@tmag4dft.org. Keep it constructive. Wanna know what I think? Well, it’s my blog, and you don’t have a choice, unless you re-direct your browser now… oh wait. One note before you move on: As this group gets off the ground, they are looking for support to pay the lawyers. Individual memberships are only $24, so make your pledge today. Just send an e-mail to Scott.Davidson@tmag4dft.org to advise him of your intend to support this noble cause. Now read on to see my opinions…
I like the definition of testability with this caveat: I wouldn’t stipulate that control/observability is necessary for those nodes ‘buried within the circuit’. it should apply to all nodes. Case in point: it’s just as important for I/O buffers to testable as it is for the most ‘buried’ node in the device. And sometimes, without proper planning, it is very difficult to control a device output so that both DC levels and AC timings can be efficiently tested.
Design for Testability: I guess I could go either way on this – Design for Testability or Design for Test? I personally prefer Design for Test. DFM has the same problem: Design for Manufacture, Design for Manufacturing, or Design for Manufacturability? According to the Wordpress spell checker, Manufacturability is not even a word. But I digress – bottom line is, we should be consistent. Why use Testability in one term, and Test in the next term…
…Structured Design for Test? I don’t have a problem with the definition of Structured Design for Test. I’ve always called it Structural DFT, but now I’m just picking nits.
Stumble It!
I find that it is useful to look at the entire chain of
testing that a product goes through.
1) A wafer is made and the die are all tested
2) Good die are packaged and a package test is done
3) Good parts are loaded on a PCA and a board test is done
4) Good boards are built into a product with a turn on test
5) The customer uses the product and does their own tests
There are three fundamental forces that determine the cost
of test.
1) Test cost goes down at each stage.
The customer test costs nothing. End of line turn on tests
tend to be quick and cheap. Wafer tests require a wafer handler, probe card and expensive testers. $$$$. This tells
us to delay testing as long as we can.
2) Test failure cost goes up at each stage
Find a defect at wafer test and you are out the wafer cost divided by the number of die on the wafer. Let the customer
find it and it is two or three orders of magnitude more expensive. This tells us to test as early as we can and
NEVER pass a bad part down to the next stage.
The conflict between these two forces is resolved by:
3) All defects are not created equal.
For each and every defect there is a unique probability that it will occur. Some will occur more often than others.
This gives us some guidelines for optimal testing.
A) Test for highly probable defects as early as possible.
If a defect is rare then it is cost effective to push it’s
testing into a later less expensive stage. The extra cost incured by catching it later is less than the extra cost
of testing every part in a earlier more expensive test.
Highly probable defects should be tested as early as possible
In the consumer market there are defects that are so rare
that it costs less to not test for them until the consumer
test and do a replacement if it fails.
B) Trade off tester time verses gates.
Gates have become so inexpensive that we are now building in
significant amounts of logic for testing because it saves
us more by reducing.
C) Reuse your tests.
There are several different engineering teams that have an
interest in any test. If the asic test engineer is going to
put in an sram bist then they design it so that it can also
run on a PCA tester or when field service plug their laptop
into the product.
John Eaton