Skip to content
VLSIMentor

DFT · Chapter 7 · Test Compression

Why Test Compression Exists

Once coverage is signed off, the remaining problem is cost. Scan shift dominates test time, and the number of top-level scan pins caps how many chains a design can have, so chains stay long and shift time stays high. Test compression breaks that pin cap. An on-chip decompressor feeds many short internal chains from just a few scan-in pins, and an on-chip compactor merges the many chain outputs back to a few scan-out pins. Because shift time now scales with the short internal chain length instead of the long external one, compression cuts test time and test data volume by roughly ten to a hundred times without losing coverage. It does not change what is tested, only how the same signed-off patterns are delivered and collected, which is why it is nearly universal in modern designs.

Foundation12 min readDFTTest CompressionTest TimeScan PinsData Volume

Chapter 7 · Section 7.1 · Test Compression

Project thread — the signed-off patterns (counter/FSM/mini-SoC, Ch3–6) are correct; compression now cuts their test time and data volume. 7.2 builds the decompressor/compactor.

1. Why Should I Learn This?

Compression is the primary lever on scan test cost (1.4) — and it's near-universal, so every DFT engineer must understand it.

  • Scan shift dominates test time (1.4); scan pins cap chain count (3.5) → chains stay long.
  • Compression: decompressor (few pins → many short chains) + compactor (many chains → few pins).
  • Shift time now tracks the short internal chain → 10–100× less test time + data volume, coverage held.
  • It changes how patterns are delivered/collected, not what's tested — the same signed-off patterns.

2. Real Silicon Story — the test budget that only compression could fix

A high-volume part had closed coverage (6.5) and balanced its chains (3.5), but the test-time and tester-memory budgets were still blown. The chains were long because the package offered only a handful of scan pins, and each pattern paid the full long-chain shift — across tens of millions of dies, the ATE time and the pattern data volume were both over budget.

The team's first instincts were capital: 'buy a bigger-memory tester' or 'run more sites.' Both treated the symptom. The real fix was architectural: add compression — a decompressor to drive many short internal chains from the few pins and a compactor to merge their outputs. Shift time collapsed to the short-chain length, test time and data volume fell ~30×, and coverage was unchanged (the same signed-off patterns).

Lesson: when chains are long because pins are scarce (3.5) and shift dominates (1.4), the answer isn't a bigger tester — it's compression, which decouples internal chain count from pin count and cuts both test time and data volume at no coverage cost.

3. Factory Perspective — compression through each lens

  • What the test engineer sees: far less shift time per die and far less pattern data to store/stream on the ATE — a direct test-cost (1.4) and tester-memory win, from on-chip blocks.
  • What the yield engineer sees: no change to which defects are caught — coverage is held — just cheaper delivery of the same test.
  • What the RTL/DV engineer sees: that compression is test-mode only — mission behavior is unchanged — and that X-sources in their logic will matter at the compactor (7.4/7.5).
  • What management cares about: a 10–100× test-cost lever (time + data volume, 1.4) at no coverage cost — often the single biggest knob on test cost per die, and why compression is standard.

4. Concept — the pin cap, and how compression breaks it

The problem (from 1.4 + 3.5):

  • Test time ≈ longest-chain shift length × patterns — shift dominates (1.4).
  • Chain count is capped by scan pins (each external chain needs scan-in/scan-out pins, 3.5).
  • So with few pins, chains are long, shift is long, and test time + data volume are high.

The compression architecture (built in 7.2):

  • Decompressor (input, on-chip): takes the few scan-in pins and spreads their data across many short internal chains — so you get the shift time of many chains with the pins of a few.
  • Compactor (output, on-chip): takes the many internal chain outputs and merges them to few scan-out pins — so the response fits the pin budget too.
  • Net: shift time now tracks the short internal-chain length, decoupled from the pin count.

What compression changes — and what it doesn't:

  • Changes: how the stimulus is delivered (compressed → decompressed) and the response collected (compacted) → less shift, less data volume.
  • Doesn't change: what is tested — the same signed-off patterns and same faults (Chapter 6). Coverage is held for well-designed compression (7.4).

The two savings:

  • Test time (1.4): shift cycles ≈ short-chain length × patterns → 10–100× less.
  • Test data volume: the tester stores/streams the compressed stimulus + compacted response → far fewer bits.

Why now (post-Chapter 6):

  • Coverage is closed and signed off (6.5). Compression is the step that makes that quality affordable — cutting cost without touching coverage. It's essentially universal in modern high-volume designs.
Few scan-in pins feed a decompressor driving many short internal chains, whose outputs feed a compactor merging to few scan-out pinsFew scan-in pinspin budget (3.5)DECOMPRESSOR(on-chip)spread few pins → manychainsMany SHORT internalchainsshift ~ short length → lesstest timeCOMPACTOR (on-chip)merge many chains → fewpinsFew scan-out pinsresponse fits pin budgetSame patterns /coveragechanges delivery, notwhat's tested12
Figure 1 - compression decouples internal chain count from pin count (representative). WITHOUT compression: a few scan pins force a few LONG external chains -> long shift -> high test time + data volume. WITH compression: the few SCAN-IN pins feed an on-chip DECOMPRESSOR that spreads data across MANY SHORT internal chains; the many chain outputs feed an on-chip COMPACTOR that merges them to a few SCAN-OUT pins. Shift now tracks the SHORT internal-chain length -> 10-100x less test time + data volume, coverage HELD. Compression changes HOW patterns are delivered/collected, not WHAT is tested.

5. Mental Model — a few loading docks feeding many short aisles

Picture a warehouse (the chip) you must stock and inspect every day.

  • Without compression: the building has only a couple of loading docks (scan pins), so goods must travel down a few enormously long aisles (long chains) — slow to fill and empty (long shift), and you must truck in a huge manifest (big data volume).
  • With compression: you install a sorting conveyor at the dock (the decompressor) that fans the incoming goods out across many short aisles (short internal chains), and a merge conveyor at the exit (the compactor) that combines the many short aisles back to a couple of shipping doors. Now each aisle is short — fast to fill and empty — even though you still only have a couple of docks.
  • Crucially, you're stocking and inspecting the same goods (same patterns/coverage) — you've only changed how they flow through the building, not what's on the shelves.
  • And you truck in a much smaller manifest (compressed data) that the conveyor expands on-site.

A few docks can feed many short aisles — that's compression: same inspection, far faster and cheaper flow.

6. Working Example — test time and data volume, with vs without

Put numbers on the compression win:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
# Test time + data volume, WITHOUT vs WITH compression - REPRESENTATIVE, SIMPLIFIED, tool-neutral:
                              WITHOUT compression        WITH compression (~30x)
  Scan pins                    8 (4 in + 4 out)          8 (same pins!)
  Chains                       4 external, LONG          120 SHORT internal (from 4 in via decompressor)
  Longest chain length         ~5,000 flops              ~170 flops (5000/30-ish)
  Shift cycles / pattern       ~5,000                    ~170            -> ~30x less shift (test time, 1.4)
  Patterns                     ~380 (signed off, Ch6)    ~380 (SAME patterns / coverage)
  Test data volume (tester)    large                     ~compressed input + compacted output -> far fewer bits
  Coverage                     target (6.5)              target HELD (well-designed; trade-offs 7.4)
# Same pins, same patterns, same coverage -> ~30x less test time AND data volume. Compression decouples chains from pins.

7. Industry Flow — compression sits after coverage, before the tester

Compression cuts the cost of the signed-off patterns on their way to the ATE:

Signed-off coverage feeds compression-aware ATPG and the decompressor/compactor architecture, cutting test time and data volume before the testerCoverage closed → compression → cheaper test on the ATECoverage closed → compression → cheaper test on the ATE1Coverage closed (6.5)signed-off patterns / target met2Decompressor + compactor (7.2)few pins ↔ many short chains3Compression-aware ATPG (7.3)patterns in the compressed domain410–100× less time + datacoverage held (1.4)5Tester (1.3)stream few bits → decompress → capture → compact
Figure 2 - compression in the flow (representative). Coverage is CLOSED and SIGNED OFF (6.5) -> the signed-off pattern set. COMPRESSION-AWARE ATPG (7.3) generates patterns for the compressed architecture (decompressor + compactor, 7.2). The result: the SAME coverage delivered with SHORT internal chains -> 10-100x less TEST TIME (1.4) + DATA VOLUME. The compressed patterns (STIL/WGL) go to the ATE (1.3), which streams few bits, the on-chip decompressor expands them, capture runs, the compactor merges the response, and few bits are compared. Compression is the cost-reduction stage between coverage closure and the tester.

8. Debugging Session — test budget blown despite balanced chains

1

Test time and tester memory are over budget even after balancing chains, and the team wants a bigger tester or more sites; the real cause is that the scan pin count caps chain count so chains are long and shift dominates -- the fix is compression, which decouples internal chain count from pins and cuts test time and data volume 10-100x with coverage held, not more capital

LONG CHAINS FROM A PIN CAP → COMPRESSION, NOT A BIGGER TESTER
Symptom

Test time and tester memory are over budget, even after balancing the chains (3.5). The proposals on the table are capital: buy a bigger-memory tester or run more parallel sites.

Root Cause

The scan pin count caps how many chains the design can have, so the chains are long, shift dominates test time, and the pattern data volume is large — a structural limit that a bigger tester treats as a symptom, not a cause. From 1.4, test time ≈ longest-chain shift length × patterns, and from 3.5, chain count is capped by scan pins (each external chain needs scan-in/scan-out pins). With only a handful of pins, you can build only a few chains, so each chain must hold many flops and is therefore long — and every pattern pays the full long-chain shift, both in ATE time and in stored pattern bits. Balancing the chains (3.5) already minimized the longest chain for the available pins, so there's no more room on that axis. The capital proposals miss the cause: a bigger-memory tester stores the same huge data volume (you haven't reduced the bits), and more sites amortizes the tester but doesn't shorten the per-die shift — you're still moving a long chain on every die. The real limit is the coupling of chain count to pin count, and neither instinct breaks that coupling.

Fix

Add test compression — a decompressor and compactor — to decouple internal chain count from pin count, cutting both test time and data volume with coverage held. Insert an on-chip decompressor that spreads the few scan-in pins across many short internal chains, and an on-chip compactor that merges the many chain outputs back to the few scan-out pins (7.2). Now the longest shift is the short internal-chain length, not the long external one, so shift cycles per pattern drop by the compression ratio (often 10–100×), and because the tester streams a compressed stimulus and collects a compacted response, test data volume drops too. Generate the patterns with compression-aware ATPG (7.3) so coverage is held (watch the care-bit/X trade-offs, 7.4). This is a far better use of engineering than capital: it attacks the structural cause (the pin cap) rather than the symptoms. The principle to lock in: scan shift dominates test time and the scan-pin count caps chain count, so chains stay long and test time and data volume stay high — test compression breaks this by using an on-chip decompressor to feed many short internal chains from a few pins and a compactor to merge their outputs back to a few pins, cutting test time and data volume 10-100x while holding coverage, because it changes only how the same signed-off patterns are delivered and collected, not what is tested; so a test-cost overrun from long, pin-limited chains is fixed with compression, not with a bigger tester. (The architecture is 7.2; EDT-style compression is 7.3; the coverage/X trade-offs are 7.4; chain balancing is 3.5; test-time economics are 1.4.)

9. Common Mistakes

  • Buying a bigger tester for a shift-time/data-volume problem. The cause is the pin cap — use compression.
  • Thinking compression changes coverage. It runs the same patterns — coverage is held (well-designed, 7.4).
  • Confusing compression with fewer patterns. It shortens shift per pattern; pattern count is ~unchanged (5.3 governs count).
  • Ignoring data volume. Compression cuts tester memory too, not just time — both matter (1.4).
  • Forgetting X-sources. They don't matter here, but they bite at the compactor (7.4/7.5) — plan for them.

10. Industry Best Practices

  • Use compression by default on high-volume designs — it's near-universal for good reason.
  • Attack test cost structurally (compression) before capital (bigger tester/sites).
  • Keep coverage held — compression-aware ATPG (7.3); watch care-bit/X trade-offs (7.4).
  • Report test time and data volume with vs without — both are real costs (1.4).
  • Plan X-source reduction early — it protects compression coverage (7.4/7.5).

11. Senior Engineer Thinking

  • Beginner: "Test time and tester memory are over budget — buy a bigger tester."
  • Senior: "Chains are long because pins are scarce (3.5), and shift dominates (1.4) — a bigger tester stores the same bits and doesn't shorten the per-die shift. I add compression: a decompressor feeds many short chains from few pins, a compactor merges them back — 10–100× less test time and data volume, coverage held. Fix the pin coupling, not the symptom."

The senior breaks the chain-count/pin coupling with compression — never buys capital for a structural cost problem.

12. Silicon Impact

Test compression is, for most high-volume products, the single largest lever on test cost, and it exists to resolve a structural tension you've met twice already: scan shift dominates test time (1.4), yet the scan-pin count caps chain count (3.5), so chains are forced long and shift stays expensive — in both ATE time and stored data volume. Compression breaks the coupling between internal chain count and pin count: an on-chip decompressor feeds many short chains from few pins, and a compactor merges their outputs back to few pins, so the longest shift becomes the short internal-chain length — a 10–100× reduction in test time and test data volume. The decisive property is that compression changes only how the patterns are delivered and collected, not what is tested — the same signed-off patterns (Chapter 6), the same faults, the same coverage (for a well-designed setup) — so it delivers quality affordably rather than trading quality for cost. That's why the right response to a test-budget overrun from long, pin-limited chains is compression, not a bigger tester (which stores the same bits) or more sites (which don't shorten per-die shift) — a structural fix beats capital. Compression is essentially universal in modern designs precisely because the pin cap is universal. For the RTL/DV engineer, two things matter downstream: compression is test-mode-only (mission behavior is untouched), and their logic's X-sources — harmless to coverage here — become the critical variable at the compactor (7.4/7.5), where unknowns can corrupt the merged response. This lesson set the why; 7.2 builds the decompressor/compactor architecture that makes it real, and the rest of the chapter turns compression from a magic ratio into an engineered trade-off you can debug and sign off.

13. Engineering Checklist

  • Confirmed the cost problem is long, pin-limited chains (shift-dominated, 1.4/3.5) — not a tester-size issue.
  • Added compression (decompressor + compactor) to decouple chain count from pins.
  • Verified coverage held (same patterns; compression-aware ATPG, 7.3; trade-offs 7.4).
  • Reported test time and data-volume reduction (1.4).
  • Noted X-sources for the compactor stage (7.4/7.5); confirmed mission-mode unaffected.

14. Try Yourself

  1. For 8 scan pins and 5,000-flop total, compute shift/pattern with 4 long chains vs 120 short chains (compression).
  2. Show the shift-time and data-volume reduction (~30×) at held coverage.
  3. Explain why a bigger tester doesn't fix a shift-dominated, pin-capped test.
  4. State what compression changes (delivery/collection) vs doesn't (what's tested).
  5. Name where X-sources will matter later (the compactor, 7.4/7.5) and why they don't matter here.

The arithmetic is tool-neutral; the architecture is representative. Real compression comes from the DFT/ATPG flow. No paid tool required to reason about why compression exists.

15. Interview Perspective

  • Weak: "Compression makes the test smaller."
  • Good: "It feeds many internal chains from few pins so shift is shorter, cutting test time."
  • Senior: "Scan shift dominates test time (1.4) and scan pins cap chain count (3.5), so chains stay long. Compression breaks the pin cap: an on-chip decompressor spreads the few scan-in pins across many short internal chains, and a compactor merges the many chain outputs back to few scan-out pins. Shift now tracks the short internal-chain length → 10–100× less test time and data volume, coverage held, because it runs the same signed-off patterns — it changes how they're delivered/collected, not what's tested. So a test-cost overrun from long, pin-limited chains is fixed with compression, not a bigger tester. It's test-mode-only and near-universal — and X-sources become critical at the compactor (7.4)."

16. Interview / Review Questions

17. Key Takeaways

  • Scan shift dominates test time (1.4) and the scan-pin count caps chain count (3.5), forcing chains long and keeping test time + data volume high.
  • Test compression breaks the pin cap with two on-chip blocks: a decompressor (feeds many short internal chains from few scan-in pins) and a compactor (merges the many chain outputs to few scan-out pins).
  • Shift now tracks the short internal-chain length, cutting test time and test data volume by roughly 10–100×, without losing coverage for a well-designed setup (trade-offs in 7.4).
  • Compression changes only how patterns are delivered and collected — not what is tested: it runs the same signed-off patterns (Chapter 6), decoupling internal chain count from pin count, and is test-mode-only (mission behavior unaffected).
  • The right fix for a test-cost overrun from long, pin-limited chains is compression — not a bigger tester (same bits) or more sites (same per-die shift); compression is essentially universal in modern designs. Next: 7.2 — compression architecture (decompressor & compactor).

18. Quick Revision

Why compression exists (Ch7 opener). Problem: scan SHIFT dominates test time (1.4) and scan PINS cap chain count (3.5) → chains stay LONG → high test time + data volume. COMPRESSION breaks the pin cap: on-chip DECOMPRESSOR (few scan-in pins → MANY SHORT internal chains) + COMPACTOR (many chains → few scan-out pins). Shift now tracks the SHORT internal-chain length → 10-100× less TEST TIME + DATA VOLUME, coverage HELD (well-designed; trade-offs 7.4). Changes HOW the SAME signed-off patterns are delivered/collected, NOT what's tested → decouples internal chain count from pins. Test-mode-only, near-universal. Fix a test-cost overrun with compression, NOT a bigger tester. Next: 7.2 — decompressor & compactor architecture.