Scan Compression
Cutting test time and test data
On a large chip, plain scan produces a huge amount of test data and takes a long time to shift in and out. Scan compression shrinks both, and it is now standard on production designs.
The problem it solves
Test cost is driven by two things: how many bits you must store on the tester (test data volume) and how many cycles you spend shifting them (test time). With thousands of flops and many patterns, plain scan can overwhelm both. Compression attacks both at once.
How it works, in concept
Compression adds a decompressor at the start of the scan chains and a compactor at the end. A small number of tester channels feed the decompressor, which spreads the data across many short internal chains. The responses from all those chains are squeezed back down by the compactor into a small signature that the tester checks.
- Decompressor: turns a few tester inputs into many internal scan inputs.
- Many short chains: shorter chains mean fewer shift cycles per pattern.
- Compactor: combines many chain outputs into a small response to check.
The result is often a ten times or greater reduction in test data and test time for the same fault coverage. The most common industry implementation is built into the scan insertion flow.
the compactor can hide a real failure if unknown values (X states) from uninitialized logic reach it and mask a faulty bit. Good DFT controls X sources (for example by tying off or bounding uninitialized memories) so compression stays reliable. X handling is a real, interview-worthy DFT topic.
the headline number to remember: compression typically buys roughly an order of magnitude less test time and data at the same coverage. That trade, less tester time for a little extra on-chip logic, is why nearly every modern SoC uses it.