DFT · Chapter 5 · ATPG

What ATPG Actually Does

Automatic test pattern generation, or ATPG, takes a design-rule-clean scan netlist and a fault list and automatically produces a compact set of test patterns, each a scan-in stimulus paired with its expected scan-out golden response, that detect as many modeled faults as possible, then reports the coverage. Be precise about what ATPG is and is not: it generates patterns, computes their golden responses, and reports coverage, but it does not make silicon good, it does not apply the patterns because the tester does that, and it does not prove zero defects because coverage is measured against the fault model. Internally it runs a loop: target a fault, search the combinational logic for a pattern that excites and propagates it, fault-simulate to drop every other fault that pattern also detects, and repeat until the coverage target is met, keeping the pattern set small and test time low.

Foundation13 min readDFTATPGTest PatternsGolden ResponseCoverage

Chapter 5 · Section 5.1 · ATPG

Project thread — the scannable counter (3.6) and FSM (4.5) are ready; ATPG now generates their patterns. 5.6 runs ATPG on the FSM end-to-end.

1. Why Should I Learn This?

ATPG is the tool that turns scan access (Ch3–4) and fault models (Ch2) into the actual patterns the tester runs.

Input: DRC-clean scan netlist (Ch4) + fault list (Ch2). Output: a compact pattern set (stimulus + golden) + coverage report.
Loop: target a fault → generate a pattern (excite+propagate) → fault-simulate to drop other detected faults → repeat.
ATPG generates patterns — it does not make silicon good, apply patterns (the ATE does), or prove zero defects.
Compact pattern sets → less shift → lower test time (1.4).

2. Real Silicon Story — 'the tool guarantees good chips,' and other myths

A new team treated ATPG's coverage report as a quality guarantee: '99% coverage means 99% good chips.' They under-invested in at-speed and memory test, assuming ATPG had it covered, and set a loose DPPM target.

Field returns corrected them. ATPG had done its job perfectly — it generated patterns and reported coverage against the stuck-at model — but that number said nothing about the timing defects (2.3) and memory faults (Chapter 8) it never modeled, and it wasn't a statement about silicon at all — it was a statement about modeled faults the patterns detect. The coverage was real; the interpretation was wrong.

Once the team understood ATPG's actual role — generate patterns and golden responses for a given model, report coverage against that model — they added the other models (2.1 portfolio) and set DPPM correctly (1.5). Lesson: ATPG is a pattern generator, not a quality oracle; the ATE applies the patterns, and coverage is versus the model, never a guarantee of good silicon.

3. Factory Perspective — ATPG through each lens

What the test engineer sees: ATPG as the pattern factory — feed it a scan netlist + fault list, get a compact STIL/WGL pattern set and a coverage number to sign off (Ch6).
What the yield engineer sees: that ATPG patterns detect the defects that get dies binned/diagnosed — the structural basis of yield sorting.
What the RTL/DV engineer sees: that ATPG's coverage is bounded by their scan-readiness (Ch4) — untestable logic caps what ATPG can do, no matter how strong the tool.
What management cares about: that ATPG is a generator, not a guarantee — coverage is versus the model (1.5), and pattern count = test time = cost (1.4), a real trade to manage.

4. Concept — inputs, the loop, and outputs

Inputs:

A DRC-clean scan netlist (Chapter 4) — full scan makes the problem combinational (3.1).
A fault list under one or more models (Chapter 2) — the denominator of coverage.
Constraints / test-mode setup — pin constraints, clocking (OCC), what's masked.

The core loop (per target fault):

Target an undetected fault from the list.
Generate a pattern that excites + propagates it (2.2) — a deterministic search over the combinational logic (D-algorithm / PODEM / FAN).
Fault-simulate that pattern against the fault list to find every other fault it also detects → drop them (so one pattern kills many faults).
Repeat until the coverage target is met or faults are exhausted/aborted (5.5).
Compact the patterns (merge/pack) → fewer patterns for the same coverage (5.3).

Outputs:

A compact pattern set — scan-in stimulus + expected scan-out (golden) response — in STIL/WGL for the tester.
A fault + coverage report — detected/undetected/redundant/aborted (5.5) and the coverage percentage.

What ATPG is NOT (lock this in):

Not a quality oracle — it generates patterns, it doesn't make silicon good.
Not the tester — the ATE applies the patterns and compares to golden (1.3).
Not a zero-defect proof — coverage is versus the model (2.1); 100% coverage ≠ 0 DPPM (1.5).

Figure 1 — the ATPG loop (representative). INPUTS: a DRC-clean scan netlist (Ch4) + a fault list (Ch2) + constraints. LOOP: TARGET an undetected fault -> GENERATE a pattern that excites+propagates it (a deterministic search over the combinational logic, enabled by scan, 3.1) -> FAULT-SIMULATE the pattern to DROP every other fault it also detects -> repeat until the coverage target. Then COMPACT. OUTPUTS: a compact pattern set (stimulus + golden response, as STIL/WGL) + a coverage report. ATPG generates PATTERNS; the ATE applies them (1.3); coverage is vs the MODEL (2.1).

What ATPG produces — and what it explicitly does not:

Figure 2 — what ATPG is and is NOT (representative). ATPG IS: a pattern generator that takes a scan netlist + fault list and outputs a compact pattern set (stimulus + golden response) and a coverage report. ATPG is NOT: a silicon-quality oracle (it makes patterns, not good chips), the tester (the ATE applies the patterns, 1.3), or a zero-defect proof (coverage is measured vs the fault MODEL, 2.1 -> 100% != 0 DPPM). Keeping this boundary clear prevents the classic mistake of reading a coverage number as a quality guarantee.

5. Mental Model — an exam-writer, not the exam-grader

ATPG is like an automated exam writer for a factory.

You give it the syllabus (the fault list — everything that could be wrong) and a well-organized student (the scannable design you can quiz directly). It writes a compact exam (the patterns) with an answer key (the golden responses) that efficiently probes every topic.
It's smart about efficiency: after writing one question, it checks which other topics that question already covers (fault-sim drop) so the exam stays short — a short exam is a cheap exam (test time, 1.4).
But the exam-writer is not the exam-grader — the tester (ATE) actually administers the exam to each student (die) and compares answers to the key.
And a high score on this exam means the student is good on the topics the exam covers — not that they're flawless (coverage is versus the syllabus/model; unmodeled topics aren't tested).

ATPG writes the exam and the answer key; the tester grades the students; and the syllabus decides what 'passing' even means.

6. Working Example — an ATPG report and a pattern

A representative ATPG run's report and one generated pattern:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# ATPG report — REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  Design            : scan-inserted block (full scan, DRC clean)
  Fault model       : stuck-at (collapsed)
  Total faults      : 12,480
  Detected (DT)     : 12,230
  Redundant (RE)    :    140   (proven undetectable -> removed from denominator, 5.5)
  ATPG-untestable(AU):    70
  Aborted (AB)      :    40   (effort limit -> raise effort to recover, 5.5)
  Patterns generated:   380   (COMPACT -> low shift/test time, 1.4)
  Test coverage     : 99.4%   (DT / (total - RE - AU))    <- vs the stuck-at MODEL (2.1)
# ATPG GENERATED these patterns + coverage. The ATE (1.3) APPLIES them. Coverage != 0 DPPM (1.5).

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# One generated pattern (STIL-style) — REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  pattern 128:
    load_unload {                         # shift in stimulus (SE=1)
      chain1 = 1011001...0 ;              # scan-in stimulus vector
    }
    capture { ... }                        # one capture (SE=0) -> logic responds
    load_unload {                         # shift out response (SE=1), compare to golden
      chain1 = 0110101...1 ;              # EXPECTED (golden) scan-out -> mismatch on silicon = detected fault
    }
# The tester loads chain1, pulses capture, shifts out, and COMPARES to the golden -> pass/fail per die.

7. Industry Flow — ATPG between scan insertion and the tester

ATPG consumes the scan flow's output and feeds the tester:

Figure 3 — ATPG in the flow (representative). Fault models (Ch2) + a DRC-clean scan netlist (Ch4) feed ATPG, which runs its target/generate/fault-sim loop to produce a compact pattern set + coverage. COVERAGE CLOSURE (Ch6) signs off the number against the DPPM goal (1.5). The pattern set is written as STIL/WGL and handed to the ATE (1.3), which APPLIES the patterns to each die and compares to golden -> pass/fail. ATPG sits between scan insertion and the tester: it turns access + models into applied test.

8. Debugging Session — treating coverage as a quality guarantee

A team reads ATPG's coverage number as a guarantee of good silicon and under-invests in other test, then sees field escapes; the misunderstanding is that ATPG generates patterns and reports coverage against a fault model -- it does not make silicon good, does not apply patterns, and coverage is not a zero-defect proof -- so the fix is to set expectations correctly and use a model portfolio plus the ATE

ATPG GENERATES PATTERNS + COVERAGE vs A MODEL — IT IS NOT A QUALITY GUARANTEE

Symptom

A team reads ATPG's coverage number as a guarantee of good silicon ('99% coverage → 99% good chips'), under-invests in at-speed/memory test, sets a loose DPPM target — and then sees field escapes.

Root Cause

ATPG generates patterns and reports coverage against a fault model — it does not make silicon good, does not apply the patterns, and its coverage is not a statement about defect-free silicon. Three conflations are at work. (1) 'Coverage = good-chip rate.' No — coverage is the fraction of modeled faults the patterns detect (2.1); it says nothing about defect classes the model doesn't include (e.g. timing defects under a stuck-at model, 2.3, or memory faults, Chapter 8), and it is not a yield or good-die percentage. (2) 'ATPG guarantees the chips.' No — ATPG is a pattern generator; the ATE must actually apply the patterns to each die and compare to golden (1.3) to sort good from bad — ATPG's report is about patterns, not parts. (3) 'High coverage → low DPPM automatically.' No — 100% coverage ≠ 0 DPPM (1.5): unmodeled defects escape, and DPPM also depends on defect density. So the team built its quality plan on a number that was doing exactly what it claimed (measuring stuck-at pattern coverage) but was misread as a silicon-quality oracle.

Fix

Set expectations to ATPG's real role, and build quality from the model portfolio plus the tester, not from one coverage number. Treat ATPG as what it is: a tool that, given a scan netlist + fault list, generates a compact pattern set with golden responses and reports coverage against that model. Then: use a model portfolio (2.1) — stuck-at plus transition/at-speed (2.3) and memory/BIST (Chapter 8) — so the defect classes your process actually produces are each covered; close coverage to the target the DPPM goal demands (1.5, Chapter 6); rely on the ATE to apply the patterns and sort dies (1.3); and keep SLT/burn-in insurance for the unmodeled tail. The principle to lock in: ATPG is Automatic Test Pattern Generation — it takes a DRC-clean scan netlist and a fault list and automatically produces a compact set of patterns (stimulus + golden response) that detect modeled faults, and reports coverage; it does not make silicon good, it does not apply the patterns (the ATE does), and its coverage is measured against the fault model, so it is never a zero-defect guarantee — real quality comes from a model portfolio, coverage closure to the DPPM goal, the tester applying the patterns, and insurance for unmodeled defects. (ATPG's reasoning is 5.2; generation + fault sim is 5.3; coverage closure is Chapter 6.)

9. Common Mistakes

Reading coverage as a good-chip rate. It's modeled-fault coverage (2.1), not a yield or defect-free number.
Thinking ATPG applies patterns. The ATE applies them (1.3); ATPG only generates them.
Trusting one model's coverage as 'quality.' Use a portfolio (stuck-at + transition + memory).
Ignoring pattern count. More patterns = more test time/cost (1.4) — compaction matters (5.3).
Expecting ATPG to fix untestable logic. Coverage is bounded by scan-readiness (Ch4) — fix the design.

10. Industry Best Practices

Treat ATPG as a generator — feed it scan-ready logic (Ch4) and a good fault list (Ch2).
Report coverage per model and close to the DPPM-driven target (Ch6, 1.5).
Value compact pattern sets — fewer patterns cut test time (1.4).
Hand STIL/WGL to the ATE — the tester applies and compares (1.3).
Never read coverage as zero-defect — plan insurance for unmodeled defects (1.5).

11. Senior Engineer Thinking

Beginner: "ATPG says 99% coverage, so 99% of our chips are good."
Senior: "ATPG generated patterns and reported 99% of the stuck-at faults covered — that's not a good-chip rate, and it doesn't apply the patterns; the ATE does. I use a model portfolio, close coverage to my DPPM target, let the tester sort dies, and keep SLT/burn-in for the unmodeled tail. Coverage is versus the model, never a quality guarantee."

The senior treats ATPG as a pattern generator and builds quality from the portfolio + tester + DPPM, not one number.

12. Silicon Impact

ATPG is the engine that converts scan access and fault models into applied test — without it, the whole apparatus of Chapters 2–4 would have nothing to run on the tester. Its value is automation at scale: it generates a compact, high-coverage pattern set for millions of faults that no human could hand-write, and 'compact' translates directly into shift cycles and test cost (1.4), so a good ATPG flow is both a coverage and a cost lever. But the most important thing to get right about ATPG is the boundary of its role, because misreading it is a classic, expensive mistake: ATPG generates patterns, computes golden responses, and reports coverage against a model; it does not make silicon good, it does not apply patterns (the ATE does, 1.3), and its coverage is not a zero-defect proof (2.1 → 1.5). Teams that treat the coverage number as a quality guarantee under-invest in the model portfolio and set DPPM too loosely, and they pay in field escapes. The correct mental model — ATPG writes the exam and answer key; the tester grades the students; the syllabus (model) defines passing — keeps the quality plan honest. For the RTL/DV engineer, the direct connection is that ATPG's achievable coverage is bounded by scan-readiness (Chapter 4): the tool is powerful, but it can only test what your design makes controllable and observable — so scan-friendly logic is what lets ATPG do its job, and the FSM of 4.5 is exactly the kind of clean target that makes 5.6's ATPG run straightforward.

13. Engineering Checklist

Fed ATPG a DRC-clean scan netlist (Ch4) and a fault list (Ch2) under the right model(s).
Ran the generate → fault-sim → compact loop to a compact pattern set.
Reported coverage per model and closed to the DPPM-driven target (Ch6, 1.5).
Handed STIL/WGL to the ATE (the tester applies/compares — 1.3).
Set expectations: coverage is vs the model, not a good-chip/zero-defect guarantee.

14. Try Yourself

List ATPG's inputs (scan netlist, fault list, constraints) and outputs (patterns + golden, coverage report).
Walk the loop: target a fault → generate (excite+propagate) → fault-sim drop → repeat → compact.
Explain why fault-sim dropping keeps the pattern set small (test time, 1.4).
State three things ATPG is NOT (quality oracle, tester, zero-defect proof) and why each matters.
Given a coverage report, explain what the number does and does not claim.

The concepts are tool-neutral. Real ATPG runs in a commercial tool; the reports/patterns here are representative. No paid tool required to reason about ATPG's role.

15. Interview Perspective

Weak: "ATPG makes test patterns to test the chip."
Good: "ATPG generates a compact set of scan patterns with expected responses to detect faults and reports coverage."
Senior: "ATPG takes a DRC-clean scan netlist and a fault list and automatically generates a compact pattern set — scan-in stimulus + golden scan-out — that detects modeled faults, plus a coverage report. Its loop is target a fault → generate a pattern that excites+propagates it (a deterministic search over the combinational logic, thanks to scan) → fault-simulate to drop every other fault it detects → repeat → compact. Crucially, it generates patterns — it does not make silicon good, does not apply the patterns (the ATE does), and its coverage is versus the model, so it's not a zero-defect guarantee. Compact pattern sets keep test time down (1.4), and coverage is ultimately bounded by scan-readiness."

16. Interview / Review Questions

17. Key Takeaways

ATPG (Automatic Test Pattern Generation) takes a DRC-clean scan netlist (Ch4) + a fault list (Ch2) and automatically generates a compact pattern set — scan-in stimulus + expected scan-out golden response — that detects modeled faults, and reports coverage.
Its loop: target a fault → generate a pattern (excite+propagate, 2.2, via a deterministic search over the combinational logic enabled by scan, 3.1) → fault-simulate to drop every other fault that pattern detects → repeat → compact.
ATPG generates patterns — it does not make silicon good, not apply patterns (the ATE does, 1.3), and not prove zero defects (coverage is vs the model, 2.1 → 1.5).
Compact pattern sets (via fault-sim dropping + compaction, 5.3) mean fewer shift cycles → lower test time/cost (1.4).
ATPG's achievable coverage is bounded by scan-readiness (Ch4) — the tool can only test what the design makes controllable/observable. Next: 5.2 — how ATPG reasons (controllability & observability).

18. Quick Revision

What ATPG actually does (Ch5 opener). ATPG = Automatic Test Pattern Generation: IN = DRC-clean scan netlist (Ch4) + fault list (Ch2); OUT = a COMPACT pattern set (scan-in stimulus + expected scan-out GOLDEN) + coverage report. Loop: target a fault → GENERATE a pattern (excite+propagate, deterministic search over COMBINATIONAL logic thanks to scan) → FAULT-SIMULATE to DROP other detected faults → repeat → COMPACT. ATPG is NOT: a quality oracle (makes patterns, not good silicon), the tester (the ATE applies them, 1.3), or a zero-defect proof (coverage vs the MODEL, 2.1 → 100% ≠ 0 DPPM). Compact set → less shift → lower test time (1.4). Coverage bounded by scan-readiness (Ch4). Next: 5.2 — controllability & observability.