More Test Points are Better

I got really involved in testability back at CrossCheck in the 1990’s when they designed a way for Gate Arrays to have 100% observability without any Design For Test (DFT) requirements on designers. The Japanese Gate Array companies loved this approach and their customers enjoyed the highest test coverage without being test experts. Fast forward to today and we find much less use of Gate Array technology, while new SoCs can have billions of transistors that need to be tested in a reasonable amount of time. About a decade ago the concept of embedded test compression came into the marketplace, a technique where the number of internal scan chains is increased while shortening their lengths. The test software can then control the contents of each short scan chain to maximize test coverage in the least amount of time. Here’s what the hardware looks like for Embedded Deterministic Test (EDT) compression:

The benefits of test compression are:

• Spending less time on the tester, which in turn saves costs
• Achieving higher fault coverage, weeding out silicon failures so a customer doesn’t receive a faulty part

Related – It’s a bouncing baby IEEE standard!

So test compression has been working well and delivering real benefits, but to keep up with growing design sizes something new had to be done to help out. That new thing is adding more test points to a design, a concept that has been around for decades but not really applied to embedded test compression. A test point means that we can control an input, or observe an output somewhere inside our logic.

The Automatic Test Pattern Generation (ATPG) software has the challenge of modeling a fault inside our logic and then tracing a path back to the inputs to control the data to stimulate the fault, and then propagating the effects of that fault to an observable output. This new approach is to automatically add test points to make the job of ATPG much easier by running faster and creating shorter patterns, decreasing test costs even more. Here’s the flow of how a test point is analyzed and inserted into a design:

This particular test flow comes from Mentor Graphics. The analysis and insertion of EDT test points can come either before or after scan insertion. Each inserted test point is selected while minimizing effects to the timing closure process. As a designer or test engineer you do have some control over where test point insertion occurs, if needed.

Related – What’s next in test compression?

Some Results

The idea of EDT test points sounds promising, but what about some actual results? Engineers at Mentor have shared results with this approach on over a dozen different designs showing a reduction in the number of patterns required for covering stuck-at faults:

There’s a typical reduction in patterns of about 3.7X, all the way up to 13X best case, so your results will vary depending on the design. For Design A to reach a stuck-at fault coverage of 99.92% required 22,244 test patterns, however when adding just 5K test points the same fault coverage was reached using only 6,373 test patterns for a 3.5X reduction.

Those are impressive results for stuck-at faults, but let’s consider transition delay faults. Here the average reduction in test patterns is 4X over the 12 designs:

There is a trade off between the number of EDT test points and test coverage so there’s no need to go overboard and add an excessive number of points, because adding more points does increase the gate count and therefore area. A utility provides data so that you can see the number of EDT test points versus pattern count, and make your own design-specific tradeoff.

A final benefit of using EDT test points is that your ATPG run times get faster by about 3.2x on average:

Summary

More test points are better and this test methodology of EDT test points will reduce the amount of ATPG patterns required to achieve a level of fault coverage. You can use this approach with either compressed APTG or regular patterns. The amount of reduced patterns is really design dependent, so why not give it a try? There’s a six page white paper at Mentor for download here that has more details.

Share this post via:

• 
• 
• 
•