Skip to content
VLSIMentor

DFT · Chapter 7 · Test Compression

Compression Architecture: Decompressor & Compactor

Test compression is built from two on-chip blocks. The decompressor sits on the input side and spreads the few scan-in pins across many short internal chains. It works because ATPG patterns are sparse: most bits are don't-cares and only a few care bits per pattern are actually specified, so a small compressed stimulus can fill many chains as long as those care bits can be produced. It is typically a linear XOR-based spreader. The compactor sits on the output side and merges the many chain outputs into a few scan-out pins with an XOR tree. Unknown handling lives here, because a single unknown on any XOR input corrupts the output and masks real fault effects, which is why compression needs masking. The central insight is that the compression ratio is limited by care-bit density.

Intermediate13 min readDFTDecompressorCompactorCare BitsXOR Tree

Chapter 7 · Section 7.2 · Test Compression

Project thread — the mini-SoC's many short chains are fed by a decompressor and merged by a compactor; 7.3 shows the EDT-style internals, 7.5 debugs a loss.

1. Why Should I Learn This?

The decompressor + compactor are the anatomy of compression — and the care-bit insight explains every compression trade-off (7.4).

  • Decompressor (input): spreads few scan-in pins → many short chains, exploiting pattern sparsity.
  • Care bits vs don't-cares: only a few care bits/pattern are specified — the decompressor fills the rest freely.
  • Compactor (output): an XOR tree merges many chains → few scan-out pins.
  • X-handling lives at the compactor (an X corrupts the XOR); ratio is limited by care-bit density.

2. Real Silicon Story — the ratio that cost coverage

A team set an aggressive compression ratio to maximize test-time savings, then saw coverage dip and pattern count rise versus the uncompressed baseline. The suspicion: the ATPG tool had gotten weaker in compression mode.

It hadn't. The problem was care-bit density. The decompressor can only produce the care bits a pattern needs by solving a linear system over the few compressed input bits — and at a high ratio (very few input bits), some patterns had more care bits than the system could satisfy. Those patterns couldn't be delivered in the compressed domain, so ATPG had to split them (more patterns) or left faults undetected — coverage loss. The tool was fine; the architecture was over-constrained for those dense patterns.

The fix was to lower the ratio slightly (more input bits → more care bits satisfiable) and spread care-bit density with a few test points (6.4). Coverage recovered. Lesson: the decompressor works by satisfying care bits from a small linear system, so the compression ratio is bounded by care-bit density — a coverage dip under aggressive compression is a care-bit limit, not an ATPG weakness.

3. Factory Perspective — the architecture through each lens

  • What the test engineer sees: the compression config — number of internal chains, the ratio, the compactor type, and any X-masking — that sets test time (1.4) and coverage-hold.
  • What the yield engineer sees: that the compactor can alias or X-mask — so diagnosis from compacted responses needs care (which chain/cycle failed).
  • What the RTL/DV engineer sees: that X-sources in their logic hit the compactor (7.4/7.5), and that care-bit density (a function of how hard their faults are, 5.2) bounds the ratio.
  • What management cares about: that the ratio is a test-time vs coverage/X-risk dial (7.4) — pushed too hard, it costs coverage or patterns; well-set, it's the big test-cost win (1.4).

4. Concept — decompressor, compactor, and care bits

The decompressor (input side):

  • Job: take the few scan-in pins and drive many short internal chains.
  • How it's possible — pattern sparsity: an ATPG pattern is mostly don't-cares; only a few care bits per pattern are specified (5.2/5.3). The decompressor must produce those care bits; the don't-cares it fills freely.
  • Structure: a linear (XOR-based) network — a spreader / ring-generator + phase-shifter (7.3). Producing the care bits = solving a linear system (over GF(2)) for the compressed input that yields them.

The compactor (output side):

  • Job: take the many internal chain outputs and merge them to few scan-out pins.
  • Structure: an XOR tree (spatial compaction) combining many chain bits into few.
  • X-handling lives here: an X (unknown) on any XOR input corrupts the output → a single X on one chain can mask real fault effects across the merged response → needs X-masking (7.4).
  • Aliasing: two fault effects on different chains can XOR-cancel (rare; mitigated by compactor design / multiple compaction).

The care-bit insight (the key to everything):

  • Compression works only because patterns are sparse (few care bits).
  • Compression ratio ≈ (internal chains) / (scan pins), but it is limited by care-bit density: if a pattern needs more care bits than the small linear system can satisfy, the pattern can't be delivered compressed → coverage loss or more patterns (7.4).
  • So the ratio is a dial bounded by how dense the care bits are — not a free parameter.
Scan-in feeds a decompressor driving many short chains, which after capture feed an XOR-tree compactor merging to few scan-out pins; care bits limit the ratio and X corrupts the compactorScan-in (few pins)compressed stimulusDECOMPRESSOR(linear/XOR)produce CARE bits; filldon't-cares freeMany short chainssparse patterns → few carebits/patternCOMPACTOR (XOR tree)merge many chains → few (Xcorrupts XOR!)Scan-out (few pins)compacted responseRatio ~ chains / pinsLIMITED by care-bit density(7.4)12
Figure 1 - the compression architecture (representative). SCAN-IN pins feed the DECOMPRESSOR (a linear XOR/spreader network) which drives MANY SHORT internal chains. It works because patterns are SPARSE -- only a few CARE bits (must-be-specified) per pattern; the decompressor produces the care bits (solving a small linear system) and fills the DON'T-CARE bits freely. After capture, the many chain outputs feed the COMPACTOR (an XOR tree) which merges them to few SCAN-OUT pins. X-HANDLING lives at the compactor: an X on any XOR input corrupts the merged output -> needs X-masking (7.4). The compression RATIO is limited by CARE-BIT DENSITY.

5. Mental Model — a mail sorter and a mail merger

Picture the chip's test as mail flowing through a building with few doors.

  • Decompressor = a mail sorter at the entrance. You hand it a short instruction ('put a red letter in slots 3, 40, and 91; anything in the rest') — because most slots don't care what they get (don't-cares), you only specify the few that matter (care bits). The sorter fans your short instruction out to fill hundreds of pigeonholes (short chains) from a couple of intake doors (scan-in pins).
  • The catch: the sorter follows simple wiring (a linear network), so it can only satisfy a limited number of specific placements at once. Ask it to put a precise letter in too many slots (high care-bit density) and it can't do it in one pass — you must send another batch (more patterns) or give up a placement (coverage loss).
  • Compactor = a mail merger at the exit. It combines hundreds of outgoing pigeonholes into a couple of outbound doors (scan-out pins) by stamping them together (XOR). But if one pigeonhole holds a smudged, unreadable letter (an X), the merged stamp is ruined — so you must pull the smudged one aside first (X-masking, 7.4).

A sorter fans few inputs into many slots (limited by how many you pin down); a merger folds many outputs into few (ruined by any smudge).

6. Working Example — care bits, the ratio, and the compactor

See how sparsity enables the ratio, and where X bites:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
# Decompressor + care bits - REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  A pattern across 120 short chains x ~170 bits = ~20,400 bits total, but only ~200 are CARE bits (~1% specified)
  -> the decompressor only needs to PRODUCE those ~200 care bits (solve a small linear system for the compressed input)
  -> the other ~99% are DON'T-CARES it fills freely -> few input bits suffice -> COMPRESSION.
  Compression ratio ~ (120 internal chains) / (4 scan-in pins) ~ 30x -- LIMITED by how many care bits the linear
  system can satisfy per pattern (care-bit DENSITY). Dense patterns -> can't satisfy all -> split/undetected (7.4).
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
# Compactor + X - REPRESENTATIVE:
  120 chain outputs -> XOR tree -> 4 scan-out pins. Normally: fault effect on a chain XORs through -> visible.
  PROBLEM: an X (unknown) on ANY chain feeding an XOR -> XOR output = X -> the whole compacted bit is UNKNOWN
    -> masks any real fault effect merged into it -> coverage loss. FIX: X-MASKING (block X-carrying chains, 7.4).
  ALIASING (rare): two fault effects on different chains XOR to 0 at the same output -> cancel -> mitigated by design.

7. Industry Flow — stimulus in, response out

The architecture defines the round-trip: compressed stimulus → decompress → capture → compact → compressed response:

The tester streams compressed stimulus, the decompressor expands it across many chains, capture runs, the compactor merges responses, and a compressed response exitsCompressed stimulus → decompress → capture → compact → compressed responseCompressed stimulus → decompress → capture → compact → compressed response1Compressed stimulus (ATE)few bits streamed to scan-in2Decompressexpand across many chains (produce care bits)3Captureone clock — logic responds4Compact (XOR tree + X-mask)merge many chains → few (7.4)5Compressed responsefew bits → compare golden (1.3)
Figure 2 - the compression round-trip (representative). The ATE streams a COMPRESSED STIMULUS (few bits) into the scan-in pins -> the on-chip DECOMPRESSOR expands it across MANY SHORT chains (producing the care bits, filling don't-cares) -> a CAPTURE clock exercises the logic -> the many chain responses feed the COMPACTOR (XOR tree, with X-masking) -> a COMPRESSED RESPONSE (few bits) exits the scan-out pins and is compared to golden. Few bits in, short shift, few bits out -> the 7.1 savings, realized by these two blocks. Care-bit density bounds the ratio; X-sources stress the compactor.

8. Debugging Session — aggressive ratio, coverage dips

1

An aggressive compression ratio causes coverage to dip and pattern count to rise versus the uncompressed baseline, and the team blames the ATPG tool; the cause is care-bit density -- at a high ratio the decompressor's small linear system cannot satisfy all the care bits of dense patterns -- so the fix is to lower the ratio or spread care-bit density (test points), not to fault the tool

RATIO IS BOUNDED BY CARE-BIT DENSITY — NOT AN ATPG WEAKNESS
Symptom

At an aggressive compression ratio, coverage dips and pattern count rises versus the uncompressed baseline. The team concludes the ATPG tool is weaker in compression mode.

Root Cause

The decompressor can only produce a pattern's care bits by solving a small linear system over the few compressed input bits, so at a high ratio some dense patterns have more care bits than the system can satisfy — a care-bit-density limit, not a tool weakness. Compression exploits pattern sparsity: the decompressor must produce the care bits each pattern needs, and it does so by solving linear equations for the compressed input that yields them. The number of care bits it can satisfy per pattern is bounded by the number of free variables — i.e. the compressed input bits, which a high ratio makes few. Most patterns are sparse enough to fit, but the densest patterns (many care bits — often the hard-to-control/observe faults, 5.2) exceed what the over-constrained linear system can produce. For those, ATPG must split the care bits across multiple compressed patterns (pattern count rises) or, if it can't, leave faults undetected (coverage dips). The ATPG engine is unchanged; the compressed delivery channel simply can't carry those dense patterns at that ratio. Pushing the ratio higher makes it worse (fewer input bits → fewer satisfiable care bits).

Fix

Lower the compression ratio slightly and/or spread care-bit density — coverage recovers; it's a channel-capacity trade, not a tool fix. Reduce the ratio (more compressed input bits → more free variables → more care bits satisfiable per pattern), trading a little test-time savings (1.4) for recovered coverage — the core compression-vs-coverage dial (7.4). Where specific dense patterns dominate, spread the care-bit density: adding a few control/observe test points (6.4) makes the hard faults easier (fewer care bits each), so they fit the compressed channel — often letting you keep a high ratio. Validate against the uncompressed baseline (the true achievable coverage) and confirm the compressed coverage matches. The principle to lock in: compression works because ATPG patterns are sparse — the decompressor only has to produce the few care bits per pattern (solving a small linear system) while filling the many don't-cares freely, and the compactor XORs many chains into few — so the compression ratio is fundamentally bounded by care-bit density: at too high a ratio the decompressor's linear system is over-constrained and cannot satisfy dense patterns' care bits, costing coverage or extra patterns, and the fix is to lower the ratio or reduce care-bit density (test points), never to blame the ATPG engine. (The concrete EDT-style linear network is 7.3; the coverage/X trade-offs are 7.4; test points are 6.4.)

9. Common Mistakes

  • Blaming ATPG for a compression coverage dip. It's a care-bit-density / ratio limit — lower the ratio or add test points.
  • Treating the ratio as free. It's bounded by care-bit density — dense patterns can't be delivered at high ratios.
  • Ignoring X at the compactor. An X on any chain corrupts the XOR — plan X-masking (7.4).
  • Forgetting aliasing. Fault effects can XOR-cancel (rare) — use good compactor design.
  • Not baselining against uncompressed. The uncompressed coverage is the true achievable — compare to it.

10. Industry Best Practices

  • Set the ratio to care-bit density — validate compressed coverage against the uncompressed baseline.
  • Use test points to spread care-bit density (6.4) — lets you keep a high ratio.
  • Design the compactor for X-tolerance / masking (7.4) — X on any chain corrupts the XOR.
  • Mitigate aliasing with robust compactor design (e.g. multiple/independent compaction).
  • Document the config (chains, ratio, compactor, masking) for diagnosis and test-cost tracking.

11. Senior Engineer Thinking

  • Beginner: "Compression dropped my coverage — the ATPG tool is weaker in this mode."
  • Senior: "The decompressor produces care bits by solving a small linear system — at a high ratio, the densest patterns have more care bits than it can satisfy, so they split or drop. The engine's fine; the channel is over-constrained. I lower the ratio a bit or spread care-bit density with test points. And I know X hits the compactor — I'll mask it (7.4)."

The senior sees a compression dip as a care-bit/ratio limit and tunes the ratio + care-bit density, not the tool.

12. Silicon Impact

The decompressor/compactor architecture is where compression's magic ratio (7.1) becomes an engineered, bounded trade-off — and the care-bit insight is the concept that makes the entire rest of the chapter predictable. The decompressor delivers the short-chain shift time within the pin budget by exploiting that ATPG patterns are mostly don't-cares — it only has to produce the few care bits each pattern needs, solving a small linear system, and fill the rest freely. That single fact explains the chapter's most important limit: the compression ratio is bounded by care-bit density, because a high ratio leaves few free variables, and the densest patterns — often the hard-to-control/observe faults (5.2) — can then have more care bits than the linear system can satisfy, costing coverage or extra patterns (7.4). So a compression coverage dip is never an ATPG weakness; it's a channel-capacity issue fixed by the ratio or by spreading care-bit density with test points (6.4). The compactor contributes the chapter's other defining issue: because it XORs many chains into few, an X on any chain corrupts the merged output, so X-handling is fundamentally a compactor problem requiring X-masking (7.4) — and any X-sources in the RTL (6.3) become critical here, which is why memories (a major X-source) drive MBIST (Chapter 8) and why X-source reduction pays off. For the RTL/DV and DFT engineer, this architecture reframes compression from a black-box ratio into two understandable blocks with two understandable limits — care-bit density (decompressor) and X (compactor) — the exact vocabulary needed to set the ratio (7.4) and debug a compression loss (7.5) on the project's mini-SoC.

13. Engineering Checklist

  • Understood the decompressor produces care bits (solves a linear system); don't-cares fill freely.
  • Set the ratio to care-bit density; validated against the uncompressed baseline.
  • Designed the compactor (XOR tree) with X-masking / X-tolerance (7.4) and aliasing mitigation.
  • Used test points to spread care-bit density where a high ratio is needed (6.4).
  • Documented the config (chains, ratio, compactor, masking) for diagnosis and test-cost (1.4).

14. Try Yourself

  1. For a pattern with ~1% care bits across 120 chains, explain why a few input bits can fill all chains.
  2. Show that the decompressor must only produce the care bits — the rest are don't-cares.
  3. Argue why a high ratio (few input bits) can't satisfy a dense (many-care-bit) pattern — the linear-system limit.
  4. Trace an X on one chain through the XOR compactor and show it corrupts the merged bit → needs masking (7.4).
  5. Give a compression ratio (chains/pins) and state what bounds it (care-bit density).

The architecture is tool-neutral; EDT-style internals are 7.3. Real configs come from the compression tool. No paid tool required to reason about the blocks.

15. Interview Perspective

  • Weak: "There's a block that compresses the input and one that compresses the output."
  • Good: "A decompressor spreads few pins to many chains, and a compactor XORs many chains to few pins."
  • Senior: "Two on-chip blocks. The decompressor spreads the few scan-in pins across many short chains — it works because patterns are sparse: only a few care bits per pattern are specified, so it just produces those care bits (solving a linear system) and fills the don't-cares freely. The compactor is an XOR tree merging many chains to few scan-out pins. Two limits fall out: the ratio is bounded by care-bit density (a dense pattern over-constrains the linear system → coverage/pattern cost, 7.4), and X-handling lives at the compactor (an X on any chain corrupts the XOR → needs X-masking). So a compression coverage dip is a care-bit/ratio issue, not an ATPG weakness — I tune the ratio or spread care-bit density with test points."

16. Interview / Review Questions

17. Key Takeaways

  • Compression is built from two on-chip blocks: a decompressor (input) that spreads few scan-in pins across many short chains, and a compactor (output) that merges many chain outputs to few scan-out pins.
  • The decompressor works by exploiting pattern sparsity: only a few care bits per pattern are specified, so it just produces those care bits (solving a small linear system) and fills the don't-cares freely — typically a linear/XOR network.
  • The compactor is an XOR tree (spatial compaction); X-handling lives here because an X on any chain corrupts the XOR output, masking real fault effects → needs X-masking (7.4); a rarer aliasing effect can XOR-cancel fault effects.
  • The care-bit insight is central: the compression ratio ≈ chains / pins but is bounded by care-bit density — at too high a ratio the decompressor's linear system is over-constrained and can't satisfy dense patterns → coverage loss / more patterns.
  • A compression coverage dip is a care-bit/ratio limit (or an X/compactor issue), not an ATPG weakness — fix it by lowering the ratio or spreading care-bit density with test points (6.4), and plan X-masking for the compactor. Next: 7.3 — EDT-style scan compression.

18. Quick Revision

Compression architecture. Two on-chip blocks. DECOMPRESSOR (input): spreads few scan-in pins → many short chains; works because patterns are SPARSE (few CARE bits, many don't-cares) — it produces the care bits (solving a small linear/XOR system), fills don't-cares free. COMPACTOR (output): XOR tree merges many chains → few scan-out pins. X-handling lives at the compactor (X on any XOR input → XOR out = X → masks fault effects → needs X-MASKING, 7.4); rare aliasing (fault effects XOR-cancel). Compression ratio ~ chains/pins but BOUNDED by CARE-BIT DENSITY: high ratio → few input bits → dense patterns over-constrain the linear system → coverage loss/more patterns. A dip = care-bit/ratio (or X) issue, NOT an ATPG weakness → lower ratio or spread care bits (test points, 6.4). Next: 7.3 — EDT-style scan compression.