DFT Digest

Design-for-test methodology and the job of the DFT engineer have grown tremendously in the last few years. The massive amounts of internal circuitry and shear speed at which it operates have outpaced classic ATE’s ability to test it. Therefore, the tester changes residence to within the confines of the device, where it can do a better job. Luckily, the EDA industry’s adoption of smart ideas from the test R&D community (and of course their own research) has stepped up to fill the gap.

Test compression, as we’ve been discussing recently in parts 0, 1, 2, and 3 so far, is an excellent example where internal circuitry eases the requirements of the external tester. ATE tester memory requirements shot through the roof with at-speed scan requirements. A technology requiring the storage of much less test data for the same fault coverage logically follows. Actually, logic BIST falls in this category also, but that’s for another discussion. Here we explore just how much test compression buys you.

Test compression allows the DFT engineer to broadcast and collect data across many multiples of internal scan chains as compared to the external chains. But if there are, say, 50 scan chains internally mapped to 1 scan chain externally, does that actually only require the storage of 2% of the non-compressed test data? The answer is no, but the actual percentage depends on a few factors:

• Type of implementation
• Desired compression ratio
• Scan friendliness of design

Before any of these factors, you start off with your internal/external chain ratio. That’s probably going to be your upper limit. The inefficiencies are introduced by the factors. Mentioned above.  The equation we’re working with is:

TDV = # of scan vectors * # of chains * depth of chains

Using test compression allows you to drastically reduce the depth of your scan chains, while keeping the number of chains (externally) the same.  The inherent inneficiencies of the test compression implementation and/or the design cause the number of scan vectors to increase.
Regarding the factors above: By type of implementation, I mean “which tool are you using?” If you’re using one with a sequential broadcasting mechanism (which I believe is only Mentor TestKompress), you’ve got a small scan chain depth adder on one end of each chain (so chain length does not reduce as much as you think). Other tools implement methods of broadcasting uncorrelated scan data using combinational logic. Cadence’s Encounter Test OPMISR compression tool, for example, uses an Illinois Scan style 1-to-1 fan-in of scan data to scan chains.

The point is that there will be limits to the amount of compression a particular implemenation style can achieve.� This says nothing about how the compression style fits into your design flow, which should be a big factor in which one you choose.

A good round-up of some of the different implementations can be seen here, and here.

The desired compression ratio will affect your final results. Try for too much compression, and the tool may end up generating more patterns. There’s a sweet spot for any given block and/or tool.

Scan friendliness, or the lack thereof can send any tool into a tailspin. Like logic BIST, test compression IP is sensitive to X-generators (usually non-scan cells or embedded memories). Since the data coming off the many parallel internal chains is compacted (data from different chains are combined), an X from one chain potentially invalidates the data from many other chains. Therefore the ATPG must generate more patterns to recover the lost fault coverage due to masking the X’s.

If the ATPG tool generated the same amount of scan vectors for the compressed version as it did the pre-compression scan implementation, you’d get TDV reduction equivalent to your external/internal chain ratio. So having to generate more patterns reduces the amount of savings.

There’s obviously quite a bit of detailed analysis that goes into planning test compression.  More than can be covered here, initially. For now I’ll move on.  I encourage anyone interested in discussing this topic to leave a comment!  I’m anxious to exchange ideas…

Hope to hear from you soon…