DFT Digest

As I blogged a couple of days ago, I’d like to write a series of posts about test compression: what it is, why you’d want to use it, it’s many variations, who in the EDA-sphere offers tools to implement it, etc.

In that previous post, I hinted at the fact that the primary reason for implementing test compression on your next chip is to address the ever-expanding volume of test vectors needed to test nanometer-scale designs. The status quo of using plain old stuck-at ATPG patterns has been broken by the need for transition fault and delay fault patterns, not to mention BIST and at-speed functional patterns.

So much for the reasons - how does test compression work?

Test compression works by reducing that ‘test data volume’ by factors of tens or even hundreds (at the extremes). Test data volume (TDV) is defined roughly, when referring to ATPG patterns, as the number of scan chains times the depth of the longest scan chain times the number of load/unload vectors. More succinctly:

TDV = # of chains x length of chains x # ATPG vectors

The maximum value of this number is going to be determined by the ATE you’re using. Let’s make up some easy numbers: You’re limited to 32 scan chains, and you have 320,000 flops in your design. That makes your scan chain length 10,000. If your ATPG generates 2000 vectors, you need:

32 x 10,000 x 2000 = 640M, or 32M per pin,

depending on how the tester is architected. And if you add at-speed ATPG patterns, that may balloon to 128M/pin, and now tour talking about expensive ATE. Of course, this brings up an important point. Always discuss the targeted ATE with your test engineer well ahead of time.

Now, what if you could magically reduce that by 10x, 50x, 100x? That’s where test compression comes in, by turning just a few external scan chains into many internal scan chains. In a picture, it looks like this:

As you can see, the data coming in from outside is ‘decompressed’, and than ‘compressed’ at the end. The outside world sees only the few external scan chains. These decompressing and compressing components are called different things for different implementations, and we’ll get into that in the next post, where we’ll explore the variations.