After horrifying experiences at 130 nanometers, design-for-yield has become a big deal. It can take many forms: Yield-aware architectural changes, yield-friendly library and memory choices, additional guard banding to reduce losses from timing variations and-perhaps the most unwelcome topic of all-adoption of the notorious recommended rules for physical design that lurk in the back of the process design kit.
But simple tweaks can help yield as well, and they aren't entirely process-dependent. One of these came up in conversation the other day with Jim Healy, who has recently taken the reins at LogicVision.
Sensibly, Healy started off at his new post by talking to a lot of customers. What he heard surprised him. While LogicVision has always been a vendor of design-for-test IP, Healy heard that one of the big reasons customers stayed with the company was not testability, but yield.
Yield? It turns out that the company's reliance on at-speed built-in self-test (BIST) has had an unintended consequence. When you write a tester program for at-speed test of a fast path, you must guard-band your pass/fail window a bit to account for variations in the delays in the test fixture, probe card and other non-IC paths. If you make the same critical delay measurement with on-chip BIST circuitry, you can eliminate that guard band. That means the BIST circuitry may correctly pass ICs the tester would fail.
For low-speed paths, this is a nonissue: the tester guard band is a small fraction of the path delay. But for very fast paths, the necessary guard band may be similar to the delay you are trying to measure. In effect, you are designing and sorting to the demands of the tester, not the requirements of the application.
It's one example of a general principle. In design-for-yield, you have to look at all the components of yield loss, not just the ones you can blame on the foundry. Could a tighter spec on package parasitics let you pass more chips? How about better cooling in the end system? A better power supply? Design-for-yield draws the design team into a conversation not just with process engineers, but with everyone downstream.
Ron Wilson covers microprocessors, programmable/reconfigurable logic and the chip design process. He can be reached at firstname.lastname@example.org.