Cost of Test - A Call to Design Teams
Pssst!! Want to boost your profit margins by a few percent? Here’s the secret: take your test to the design (you know… DFT!). This is the message of a commentary by Jim Healy, CEO of LogicVision.
“Manufacturing should have the ability to drive test cost and final package yield criteria into design specs…”
Like a whisper to a scream, such is the mantra of the the entire DFM movement this year. I couldn’t agree more. The hard part is implementing those “design specs” during the design phase. A score of start-ups, each one pushing to develop the next killer design tool, are betting it can be done.
Now, a commentary from the CEO of LogicVision must contain the obligitory plug for BIST vs. ATPG. Stated as such, I’ll agree. Just ATPG is obviously not sufficient.
But I guess I’m not totally won over in the BIST vs. ‘ATPG + compression + at-speed scan’. In the ‘ease of use’ column, I’m thinking it’s a wash, if not a slight victory for ATPG. I think at-speed scan targeted toward small-delay defects will go farther in the yield improvement category than BIST. Diagnostics? Not sure…
But unless there exists an explicit requirement for some POST-like self-test to be used in the field, I’m going with ATPG+.
Am I wrong?
December 1st, 2006 at 11:58 am
LogicBIST requires much stricter DRC rules. Generically fault coverage with PRPG random patterns is not enough to ensure the test quality. Test points have to be added to bump up the coverage, and it doesn’t help small delay detection very much. In LogicBIST, if a scan flop is screwed, the whole chain is screwed. If you run into bad signature, debug process will be a nightmare. Also test effectiveness with LogicBIST is questionable. There are a lot of repeatitions during LogicBIST test. Nobody will say test effectiveness is improved after repeating applying scan-based patterns N times.
December 4th, 2006 at 11:15 pm
[...] Logic BIST is a more complicated implementation (see some notes on that in this comment), but does have the advantage of being useful all the way into field, and is an even more compact vector set than a test compression implementation. Test compresion is easier to implement, and is more capable of targeting the small delays, if the tool is built right. Due to the fact that both approaches compact their response data, neither of them likes structures that produce undetermined values (X’s). These structures complicate the implementation. Unfortunately in a typical design, there are many complicating factors. One of the most common ones would be embedded memory, notorious X-generators during scan. They must be controlled (usually by bypassing them) during test mode. Any other non-scan entities will cause the same problems. Another likely place in a typical SOC would be an analog-digital boundary. [...]