DFT Digest

Any good introduction to a topic starts with some discussion of motivation. DFT is no exception. In fact, over the years, most DFT and test engineers have spent more time than they would have liked justifying to designers and design managers the inclusion of test hardware in electronics products.

It’s seemed to me through the years that the only thing designers were taught about design-for-test was that it made their designs bigger and slower, something to avoid. Unfortunately, there is truth to that: one of the biggest concerns in most of today’s challenging designs is power, and smaller designs normally use less power. So it seems that we DFT folk are always at least somewhat at odds with the marketing requirements…

My own path to design for test was hacked out of desperation, after spending years on the ATE trying to implement functional patterns that, in the end, were not even sufficient enough to keep me (or some poor product engineer) from seeing devices again as customer returns. In a lot of cases, this was an acceptable use of my time, and being in a more consumer oriented market, was not critical to life or limb in the field.

Fortunately however, we do have an analysis weapon to use, pre-tapeout, in this fight, and any book on electronics test will have a section devoted to it: the economics of test. It remains the single most useful tool to determine whether or not to include a test feature as part of a design.

More below the fold…

Now, as silly as it sounds coming from an engineer, I’m not a numbers guy. I’m sure it’s made things hard for me over the years. I operate by intuition a bit more than I should. With that in mind, I’ll try to explain the essence of the economics that are ultimately explained with mathematical equations in more complete treatments, to which I will refer.

One of the more well known rules-of-thumb cited in defense of facilitating test earlier in the product cycle is the rule-of-ten, which states that as an electronice device is manufactured, put on a board, and that board put in a system, it costs ten times as much to diagnose a defect at each subsequent level down the line. In other words, if you don’t catch a faulty device at device test, it’ll cost 10x to catch it at board test.

The other rule-of-thumb I’ve always quoted, which even less scientific, but true nevertheless, is that even a good set of functional patterns thrown at a decently complex design will only field 65-75% stuck-at fault coverage (applies to random sequential logic; embeded memory fault coverage could be worse). This rule alone is why scan/ATPG and memory BIST are the baseline de-facto standards for manufacturing test of an IC.

Beyond that, there are a host of other cost issues such as ATE costs, development costs, EDA tool costs, and the incremental effect on yield as your die size grows due to embedded test structures. These all must be weighed and balanced when evaluating a test approach.

There’s a lot to analyze, but when it comes to DFT, the hope is that over the life of a product, you will save enough in ATE costs (lower test times and cheaper equipment) and ship enough good parts to overshadow the cost of the tools and man hours needed to embed test IP in your product.

Anybody want to tackle a more detailed discussion?