Design for Testability: Why Scan Compression Becomes Mandatory

There is a common assumption embedded in how engineers first encounter scan design: that once you have full scan insertion, the hard work is done. The flip-flops are accessible, the ATPG engine can reach every node, and fault coverage targets are achievable. On paper, nothing is missing.

What that view ignores is cost specifically, the cost of actually moving test data between the chip and the tester. Scan gave us access to the interior of the device. But as transistor counts scaled upward and as the gap between what a chip contains and what a tester can handle grew wider, delivering that access became the dominant constraint. The question stopped being “can we test this?” and became “can we afford to test this?”

That is the context in which scan compression stops being an optimization and becomes a design requirement.

The Numbers Behind the Problem

To understand why compression is necessary, it helps to work through the arithmetic of uncompressed scan test at modern transistor counts.

A contemporary high-performance SoC a mid-range mobile application processor, for instance can contain upward of 10 to 20 million flip-flops subject to scan insertion. A full-scan ATPG run targeting stuck-at and transition fault coverage at 99% will typically produce somewhere between 10,000 and 100,000 test patterns, depending on design complexity, clock domain structure, and logic cone depth.

Each pattern requires shifting data into and out of every scan cell. With 10 million flip-flops organized into, say, 1,000 parallel chains of 10,000 cells each, one shift operation requires 10,000 clock cycles per chain. A single test pattern one shift-in, one capture, one shift-out therefore consumes roughly 20,000 tester cycles (10,000 to shift in, 10,000 to shift out, with the capture in between). Across 50,000 patterns, the total tester cycles for the scan test alone reaches:

Shift cycles per pattern  = 2 × chain_length
                          = 2 × 10,000
                          = 20,000 cycles

Total tester cycles       = patterns × cycles_per_pattern
                          = 50,000 × 20,000
                          = 1,000,000,000 cycles (10^9)

At 100 MHz tester clock   → 10 seconds of test time per device

Ten seconds may sound manageable in isolation. But at volume a production line running thousands of devices per day test time translates directly to tester occupancy, which translates directly to cost per die. A one-second reduction in test time per device across a million-unit production run represents one million seconds of freed tester capacity. The economics are unforgiving.

And this estimate is conservative. It uses a relatively modest flip-flop count, a moderate pattern set, and a generous tester clock frequency. For a design with 50 million flip-flops and 200,000 patterns which is not unusual in a high-end GPU or networking SoC the test time without compression becomes genuinely prohibitive.

The ATE Bandwidth Problem

The automatic test equipment (ATE) problem is not merely one of time it is also one of physical bandwidth.

An ATE communicates with the device under test (DUT) through its pin electronics: the hardware channels that drive stimulus onto each pin and capture response from each pin. These channels are the physical interface between the tester’s memory and the device. Every scan-in pin requires a dedicated channel driving test data, and every scan-out pin requires a channel capturing response data.

The fundamental constraint is this: pin electronics counts on ATE have not scaled proportionally with transistor counts on silicon.

Transistor counts have followed something close to Moore’s Law roughly doubling every two years through much of the history of the industry. ATE pin counts have grown far more slowly, constrained by the physical cost of each channel (the analog components, the timing calibration hardware, the cabling), the power dissipation of the tester head, and the sheer mechanical complexity of making high-frequency contact to hundreds of pins simultaneously.

A rough measure of test complexity can be expressed as the ratio Nt/Np — the number of transistors on the chip divided by the number of peripheral I/O pins. Industry roadmap data from the late 1990s showed this ratio already reaching values on the order of 11,000. In more recent designs, it is significantly higher. — VLSI Design Verification and Test, University of New Mexico

The implication is structural. The silicon side of this ratio scales aggressively. The tester side does not. Every generation of process technology widens the gap between how much testable content exists on the die and how much bandwidth the ATE can supply to reach it.

Silicon Scaling (approximate):
  Year N:    1B  transistors,  500  scan FFs/pin
  Year N+2:  2B  transistors,  550  scan FFs/pin  (pin count grows slowly)
  Year N+4:  4B  transistors,  620  scan FFs/pin
  Year N+6:  8B  transistors,  700  scan FFs/pin

The per-pin burden grows with every process generation.
Without compression, either test coverage drops or test time explodes.

This is not a problem that can be solved by simply buying more expensive testers. High-pin-count ATE platforms exist, but their cost scales steeply with pin count and channel frequency. The capital cost of an ATE with thousands of high-speed pin electronics channels can reach several million dollars per unit. Depreciated across a production run, the cost per test second is non-trivial — and the test time for an uncompressed large design at full coverage can easily exceed the economic threshold.

For a more detailed overview of ATE architecture and its cost structure, Siemens EDA (formerly Mentor Graphics) have published accessible introductions:

• Siemens EDA — Using EDT Test Points to Reduce Test Time and Cost
• VLSI Testing Process Overview — UNM ECE

The Care-Bit Observation

There is a property of ATPG patterns that creates the opening for compression, and it is worth understanding precisely.

When an ATPG engine generates a test pattern for a given set of target faults, it assigns specific logic values to a subset of scan cells — the cells that need particular values to activate the target faults, propagate their effects, or constrain logic cones during capture. These cells are called specified bits or care bits.

The remaining scan cells in the pattern are unspecified. The ATPG engine does not care what value they hold, because those cells do not affect the detection of the target faults in that pattern. Their values are typically filled with pseudo-random data or left as X (don’t-care).

In practice, the ratio of care bits to total bits in a well-generated ATPG pattern is small. Empirical data from industrial designs consistently shows that only 1% to 5% of scan cell values in a typical ATPG pattern are specified. The other 95% to 99% are don’t-care. Typical ATPG Pattern Structure:

Total scan cells in design:        1,000,000
Care bits per pattern (avg ~2%):       20,000
Don't-care bits per pattern:          980,000

In conventional uncompressed scan:
  → All 1,000,000 bits are shifted in from the tester, even though
    only 20,000 of them are meaningful.

Information density per pattern:  2%
Waste per pattern:                98%

This observation is the foundational justification for scan compression. The tester is spending 98% of its shift bandwidth moving data that carries no fault-detection value. If that don’t-care space can be exploited if a mechanism exists to encode the 2% of meaningful bits into a compact external representation and expand them on-chip then the external test data volume can be reduced dramatically without any reduction in fault coverage.

The Compression Principle: External vs. Internal Data

Scan compression is architecturally simple in principle, even though its implementation involves careful engineering.

The core idea is to decouple the external data width (the number of scan channels the tester drives) from the internal data width (the number of scan chains inside the design). A small number of external channels driven by the tester feed into an on-chip decompressor, which expands the incoming data into a larger number of internal scan chains. On the output side, an on-chip compactor collects responses from all internal chains and compresses them into a smaller number of output channels back to the tester. Without Compression:

  ATE (1000 pins) ─────────────────────────────── 1000 scan chains
                   one-to-one correspondence
                   tester drives every chain directly

With Compression:

  ATE (32 channels) ──► [DECOMPRESSOR] ──► 1000 internal scan chains
                              │
                              ▼
                        32 × compression
                        ratio = 31.25×

  1000 internal chains ──► [COMPACTOR] ──► 32 output channels ──► ATE

  External bandwidth: 32 channels
  Internal bandwidth: 1000 chains
  Compression ratio:  ~31×

The decompressor is not simply duplicating the 32 input channels onto 1000 outputs — that would create dependencies between chains and prevent independent control of each. Instead, it uses linear feedback mechanisms like XOR networks, ring LFSRs, or phase shifters(more on this in upcoming blogs) to generate a large number of pseudo-independent bit streams from the small number of external inputs. The ATPG tool, which understands the decompressor’s transfer function, generates patterns that, when fed through the decompressor, produce the required care bit values at the correct internal scan cell positions.

This is the critical architectural insight: the don’t-care bits in the ATPG pattern are not wasted space they become degrees of freedom that the compression algorithm uses to solve the decompressor encoding problem. The sparsity of care bits is precisely what makes compression feasible. If every bit in every pattern were specified, there would be no flexibility to find a compact external encoding.

The compactor on the output side uses a complementary XOR-based structure to fold multiple chain outputs into fewer channels. This introduces the possibility of aliasing two different fault responses mapping to the same compacted output but the probability of undetected aliasing is made negligibly small through careful compactor design and X-masking strategies.

Why This Is Not an Optimization

The framing of scan compression as a design option something you add if you want to improve test efficiency is technically accurate but practically misleading.

At process nodes below 28nm, for designs with more than a few million flip-flops, the test data volume of an uncompressed full-scan ATPG run at target coverage will exceed the storage capacity of realistic ATE configurations, or the test time will exceed the economic threshold for production test, or both. These are not edge cases. They are the expected outcomes for any competitive SoC at advanced nodes.

The ITRS (International Technology Roadmap for Semiconductors) and its successor, the IRDS, have tracked the test cost and ATE bandwidth gaps for decades. The conclusion has been consistent: without on-chip test data reduction, test cost grows faster than design value at each successive process node. This is sometimes called the test cost crisis.

From a flow perspective, this means compression infrastructure decompressor logic, compactor logic, scan channel definitions must be planned at the DFT architecture stage, before scan insertion. It affects the scan chain count, the scan channel pin assignments, the ATPG configuration, and the test protocol. It is not something that can be bolted on after the fact without significant re-insertion effort.

The decision is not whether to use compression. For any serious production design at advanced nodes, that decision has already been made by the constraints of physics and economics. The engineering decisions that remain are about compression architecture, compression ratio, compactor design, and the interplay between compression and the physical scan topology established in the previous article. Those are the topics this series will address next.

What Compression Does Not Change

It is worth being precise about the boundary of what compression achieves.

Scan compression reduces the external test data volume the bits that flow between the tester and the chip. It does not reduce the number of internal scan cells, the number of internal chains, or the total number of shift cycles occurring inside the device. Internally, the design still performs the same number of shift and capture operations as it would without compression. The silicon area consumed by scan flip-flops is unchanged.

What changes is the tester’s view of the device. From the tester’s perspective, the chip presents 32 (or 64, or 128) scan channels, not 1000. The tester stores and drives only the compressed representation of the test data. The chip does the work of expanding and compacting, and it does so using hardware that is small relative to the scan cell count typically 1% to 3% area overhead for the compression logic itself.

The internal test quality i.e the fault coverage achieved by the expanded patterns can be maintained at the same level as uncompressed full-scan, provided the compression architecture is correctly configured and the ATPG tool accounts for the decompressor’s transfer function when generating patterns.

What Compression Changes: ✓ External test data volume (reduced by compression ratio) ✓ Tester memory requirement (reduced) ✓ Tester time per device (reduced) ✓ Scan channel pin count required (reduced) What Compression Does NOT Change: ✗ Internal scan cell count ✗ Internal chain count ✗ Fault coverage target ✗ On-chip shift clock frequency ✗ ATPG fault models used

This distinction matters because it defines what problem compression solves and what problems remain. After compression, the internal scan topology still needs to be physically optimized — the chain balancing and physical-aware stitching challenges from the previous article do not disappear. They now interact with the compression architecture in ways that require careful co-optimization, which is the engineering content the next several articles in this series will unpack.

Closing Remarks

The case for scan compression rests on three observations that are each individually sufficient, and together are decisive.

First, transistor counts scale exponentially while ATE pin bandwidth scales slowly — the ratio of internal testable content to external test bandwidth widens with every process generation. Second, uncompressed test data volume for a large design at target coverage exceeds practical tester storage and time budgets. Third, ATPG patterns are inherently sparse in specified bits, which means the information content of the test data is far smaller than its raw bit volume — creating space for lossless or near-lossless compression without coverage impact.

Compression is the mechanism that reconciles the silicon’s testability requirements with the physical reality of what ATE can deliver. Understanding why it exists — not just how it is implemented — is what allows a DFT engineer to make correct architectural decisions when the tradeoffs between compression ratio, fault coverage, X-tolerance, and physical scan topology must be balanced simultaneously.

The next article will examine the specific architectures through which compression is implemented: the decompressor topologies, the compactor designs, and the engineering choices that determine how much compression is achievable before coverage begins to degrade.

Further Reading:

• Siemens EDA Tessent — EDT Test Compression Overview
• VLSI Tutorials — Test Compression and EDT Architecture
• UNM ECE — The VLSI Testing Process and ATE
• Academia — Scan Compression Techniques: EDT and Broadcast Architectures

This article is part of my ongoing series on Design for Testability. Previous entries cover fault modeling, ATPG fundamentals, scan cell architectures, scan design implementation, scan chain balancing, and physical-aware scan stitching. The full series is available on my Medium profile.

Connect with Me:

• GitHub: ranaumarnadeem
• LinkedIn: Rana Umar Nadeem

VLSI #ASICDesign #LogicSynthesis #ClockGating #LowPowerDesign #RTLDesign #DigitalDesign #DFT #BackendDesign #EDA #Cadence#Genus #Sky130 #RTLtoGDSII #SemiconductorEngineering #TechBlog #modus #scan_chains #scancompression #xornetworks