In short: Test cost is dominated by seconds-on-the-tester, so engineers cut it by testing many dies at once (multisite/parallel), shrinking pattern volume with scan compression, and spending test time only where it buys real defect coverage.
In a high-volume product the automatic test equipment (ATE) is often the single most expensive machine the silicon ever touches. A modern digital tester can cost several million dollars, and its amortized cost is billed by the second. When you ship a hundred million units a year, trimming 300 ms off each insertion is not a rounding error — it is millions of dollars. This article walks through the three levers post-silicon teams actually pull to reduce test cost, and the engineering tradeoffs behind each.
Where the money actually goes
Test cost per device is roughly the tester's hourly rate divided by the number of good dies it processes per hour. That decomposes into three attackable terms: how many dies you test simultaneously (parallelism), how long each die occupies the tester (test time), and how often you re-handle a die (insertions, e.g. wafer sort plus final test). A $3M tester running three shifts amortizes to roughly $0.80–$2.00 per second of occupied capital and depreciation. If a part needs 800 ms of test, that is on the order of 1–2 cents per part before you even count the handler, load board, and operator.
Key fact: At 150 ms of scan test and $1.20/tester-second, each die costs ~$0.18 in test alone. Doubling site count to test two dies in that same window halves the per-die figure to ~$0.09 — the fastest money you will ever save.
Lever 1 — Multisite and parallel test
Multisite means the tester drives N devices at the same time from shared resources. Wafer probe cards now contact 32, 64, or even 256 sites in one touchdown; final-test handlers commonly run 4-, 8-, or 16-site in parallel. The economics are blunt: if the test program is 100% parallel-efficient, test cost per die drops by the site count. Reality is lower because some operations are inherently serial.
The limiting metric is multisite efficiency = (single-site time) / (N × per-site time in the parallel program). Leakage ties it down: shared DC instruments can only force/measure one supply at a time, so IDDQ and trim measurements often serialize across sites. If a 16-site program spends 40 ms in parallel scan but 10 ms per site in serial analog trim, the serial portion (160 ms) dominates and efficiency collapses. The fix is per-site resources — per-pin parametric measurement units (PPMUs) and per-site device power supplies — which raise board cost but recover the parallelism. Platforms like Advantest V93000 and Teradyne UltraFLEX are specified around exactly this scaling.
Lever 2 — Scan compression
Stuck-at and transition-fault patterns applied through scan chains used to dominate test time and ATE vector memory. Compression breaks that wall. A decompressor expands a few tester channels into hundreds or thousands of internal scan chains, and a compactor (typically a MISR/XOR network) folds the captured responses back down. Siemens EDA's TestKompress (the EDT architecture), Synopsys DFTMAX/TestMAX, and Cadence Modus all implement this. Compression ratios of 50×–200× in both pattern count and data volume are routine; at advanced nodes teams push toward 400×.
Less data means fewer shift cycles, which directly shortens test time, and it means the pattern fits in tester memory so you avoid expensive reloads. The catch is the compactor can mask faults: unknown (X) values from uninitialized RAM or non-scan logic corrupt the MISR signature, and aggressive compaction can let two faults alias to the same signature. X-tolerant compactors and careful X-bounding during ATPG recover most of that coverage, but there is a real floor — this is the first place the test-time-versus-coverage tradeoff bites.
| Metric | No compression | 100× compression |
|---|---|---|
| Scan chains | 32 | 3,200 (internal) |
| Shift cycles / pattern | ~4,000 | ~40 |
| Pattern data volume | 8 Gb | ~90 Mb |
| Stuck-at coverage | 99.2% | 99.0% |
Lever 3 — The test-time vs coverage curve
Fault coverage versus pattern count is a classic diminishing-returns curve: the first patterns catch the easy, high-probability faults; the last fraction of a percent of coverage can take as many patterns as the first 95%. The business question is never "maximum coverage" — it is "what defects-per-million (DPPM) does my customer tolerate, and what is the cheapest test that hits it?"
Teams exploit this with pattern ordering and abort-on-fail: ATPG tools rank patterns by incremental fault detection, so a bad die usually fails in the first few patterns and gets binned out immediately instead of running the full suite. On good dies you still run everything, but you choose the suite deliberately — perhaps full stuck-at plus a reduced transition-fault set, dropping the long tail of hard-to-detect faults that your field-return data shows never escape. Cell-aware and gate-exhaustive patterns are added selectively only on the nodes and products where defect-density data justifies the extra seconds.
Key fact: Moving from "all patterns" to abort-on-first-fail typically cuts average test time at wafer sort by 20–40% at mature yield, because most of the rejects are caught early and never consume the full program.
Putting the levers together
The levers multiply. A single final-test program might combine 8-site parallelism, 100× scan compression, and abort-on-fail ordering — each independently cutting cost, together turning a would-be 2-second, single-site test into something under 100 ms per good die. The discipline is measurement: instrument the test program, log per-pattern and per-site timing, and attack whichever term is actually dominating. If you are curious how these choices connect to the tester hardware itself, our companion piece on ATE (automatic test equipment) covers the platform side, and the DFT scan insertion guide explains how the on-chip structures are built. For teams standing up production test flows, the design-services group at Avecas (silicon design and DFT services) handles this end to end.
Want to go from "I know the terms" to building a cost-optimized test program yourself? CourseTron's post-silicon and DFT track walks through ATPG, compression, and multisite economics with real tool flows — explore the courses.
Frequently asked questions
Does scan compression reduce fault coverage?
Slightly, if done carelessly. The compactor can mask faults through X-values or aliasing, which may cost a few tenths of a percent of coverage. Modern X-tolerant compactors and X-bounding during ATPG keep the loss small enough that most teams accept it for the 50×–200× data reduction.
What is a good multisite efficiency target?
For a digital-heavy part, 85–95% efficiency at 8 or 16 sites is achievable. Analog/mixed-signal parts are harder because DC measurements serialize; 60–75% is common there unless you add per-site parametric resources.
Why not just run the maximum pattern set for best quality?
Because coverage versus test time has a sharp knee. Past ~99% stuck-at, each additional point of coverage costs disproportionate seconds and delivers only marginal DPPM improvement. You size the test to the customer's quality requirement, not to the theoretical maximum.
Which costs more to cut, test time or insertions?
Eliminating a whole insertion (e.g. merging tests so you skip a separate burn-in screen) usually saves the most because it removes handling, load-board, and setup overhead — but it is only safe when your reliability data shows the screen is not catching real escapes.