Pattern Generation & Fault Simulation

Chapter 5 · Section 5.3 · ATPG

Project thread — this generate/fault-sim/compact loop is what produces the compact pattern set for the FSM in 5.6.

1. Why Should I Learn This?

This loop is why ATPG pattern sets are small — and small pattern sets are why scan test is affordable (1.4).

• Pattern generation: the deterministic search makes one pattern per target fault (5.2).
• Fault simulation: finds all other faults that pattern also detects → drop them (one pattern kills many).
• Random-fill first (cheap, easy faults), deterministic for the hard remainder.
• Compaction (static + dynamic) + the coverage curve (fast then flat) → few patterns, high coverage.

2. Real Silicon Story — the pattern set that was 50x too big

A team generated patterns with fault dropping turned off in their setup and no compaction — effectively one pattern per targeted fault. The result: a massive pattern set, enormous test time (1.4), and a multi-day ATPG runtime. They assumed the design was just 'hard.'

It wasn't. Enabling fault-simulation dropping meant each generated pattern got credit for the hundreds of other faults it also detected, so the vast majority of faults were dropped without ever being individually targeted. Adding a random-fill first pass knocked out the easy 80% almost for free, leaving deterministic ATPG only the hard remainder. Turning on compaction merged and packed the rest. The pattern set collapsed by roughly 50x, runtime fell to minutes, and coverage was unchanged.

Lesson: a bloated pattern set is almost always a flow problem — missing fault dropping, random-fill, or compaction — not a hard design. The generate → fault-sim-drop → compact loop is what makes ATPG efficient.

3. Factory Perspective — the loop through each lens

• What the test engineer sees: the pattern count and coverage curve — the direct inputs to test time (1.4) and signoff (Ch6); they tune random-fill, effort, compaction.
• What the yield engineer sees: that fault simulation underpins diagnosis — mapping a failing pattern to the faults it detects narrows the defect.
• What the RTL/DV engineer sees: that the coverage curve's flat tail is their hard-to-test logic — the test-point candidates (Ch6).
• What management cares about: that a compact pattern set is lower test cost (1.4) at the same coverage — a direct cost lever from the ATPG flow, not a quality trade.

4. Concept — generate, fault-sim/drop, random-fill, compact

Pattern generation (deterministic):

• The 5.2 search produces one pattern that detects a specific target fault (justify + propagate).
• Expensive per fault → you don't want to do it for every fault.

Fault simulation (the multiplier):

• Given a pattern, simulate the faulty machines to find every fault that pattern also detects.
• Fault dropping: remove all those from the target list — so one generated pattern credits many faults.
• Fault sim also computes the golden response and validates the running coverage.

Random-fill first, deterministic for the hard remainder:

• Phase 1 — random/pseudo-random + fault sim: cheap patterns detect the easy faults fast → high initial coverage for little effort.
• Phase 2 — deterministic ATPG (5.2): target only the hard remainder the random patterns missed.
• This split is standard because most faults are easy and only a minority need the expensive search.

Compaction (shrink the count):

• Static: after generation, merge compatible patterns (unspecified bits let two patterns combine).
• Dynamic: during generation, pack multiple target faults into one pattern (fill don't-cares to detect extra faults).
• Both cut pattern count → test time (1.4), coverage unchanged.

The coverage curve (diminishing returns):

• Coverage rises fast (random-fill + easy faults) then flattens (hard faults need expensive, per-fault work).
• The flat tail tells you when to stop and where test points (Ch6) would raise coverage more cheaply than more patterns.

The two engines play different roles — generation is expensive, fault sim multiplies its value:

5. Mental Model — a quiz-writer who reuses questions

Imagine writing a quiz to test a student on 10,000 topics, but you want the shortest quiz possible.

• Writing one question per topic = 10,000 questions (a pattern per fault) — absurd.
• Instead, after you write one good question (a generated pattern), you check which other topics it also tests (fault simulation) and cross them off (fault dropping). A single well-chosen question might cover hundreds of topics.
• You warm up with a batch of random questions and cross off everything they happen to cover (random-fill) — that clears the easy 80% for free — then you hand-craft questions only for the stubborn remainder.
• Finally you merge questions that fit together and pack extra topics into spare parts of each question (compaction).
• The coverage-vs-questions graph shoots up then levels off — the last few topics cost the most questions, telling you when to stop.

You don't write a question per topic — you write one, credit it for everything it covers, and reuse aggressively. That's fault dropping.

6. Working Example — a run where one pattern drops many faults

Watch the loop shrink the pattern count:

# Generation + fault dropping — REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  Total faults (collapsed) = 12,480
  PHASE 1 random-fill (200 random patterns + fault sim): drops ~10,000 EASY faults -> coverage ~80% almost free
  PHASE 2 deterministic ATPG on the HARD remainder (~2,480):
    generate pattern for target fault F -> FAULT SIM: this pattern ALSO detects ~150 other faults -> DROP all 151
    -> next target is a still-undetected fault -> generate -> fault-sim-drop -> repeat
  -> only ~180 DETERMINISTIC patterns needed for the remainder (each drops many)
  COMPACTION (static + dynamic): 380 total -> 300 patterns, SAME coverage
  Final: ~300 patterns, 99.4% coverage   (vs ~12,000 if one-pattern-per-fault!)  -> low test time (1.4)

# Coverage curve (diminishing returns) — REPRESENTATIVE:
  patterns:    0    50   100   200   300     # cumulative
  coverage:    0%   72%  90%   98%  99.4%    # rises FAST (easy) then FLATTENS (hard) -> where test points help (Ch6)
# The flat TAIL = hard-to-control/observe faults (5.2). Adding patterns there costs a lot for little gain.

7. Industry Flow — the loop inside the ATPG run

Generation and fault sim alternate to build a compact set, feeding coverage closure:

8. Debugging Session — pattern count and runtime are enormous

9. Common Mistakes

• Disabling fault dropping. ATPG re-targets already-detected faults → pattern explosion — keep dropping on.
• Skipping random-fill. The easy 80% get the expensive search → wasted runtime — random-fill first.
• Turning off compaction. Mergeable/packable patterns stay separate → more test time (1.4).
• Chasing the flat tail with patterns. Diminishing returns — the tail wants test points (Ch6), not more patterns.
• Blaming the design for a big pattern set. It's usually a flow misconfiguration, not hard logic.

10. Industry Best Practices

• Always fault-simulate and drop — one pattern should credit many faults.
• Random-fill first, deterministic for the hard remainder — the efficient split.
• Use static + dynamic compaction — minimize pattern count (test time, 1.4).
• Read the coverage curve — stop where it flattens; use test points for the tail (Ch6).
• Treat a bloated pattern set as a flow bug — check dropping/random-fill/compaction first.

11. Senior Engineer Thinking

• Beginner: "The pattern set is huge and ATPG runs for days — the design must be hard."
• Senior: "That's a one-pattern-per-fault signature — fault dropping, random-fill, or compaction is off. With dropping, each pattern credits hundreds of faults; random-fill clears the easy 80% free; compaction packs the rest. Turn them on and the set collapses, coverage unchanged. The flat tail wants test points, not more patterns."

The senior reads a bloated pattern set as a flow issue and restores dropping + random-fill + compaction.

12. Silicon Impact

Pattern generation and fault simulation are the efficiency heart of ATPG — the reason a design with millions of faults yields a pattern set of mere hundreds and therefore an affordable test (1.4). The key insight is a division of labor: deterministic generation (the expensive 5.2 search) is used sparingly, only for hard target faults, while fault simulation — cheaper — multiplies each generated pattern's value by crediting and dropping every other fault it detects, and a random-fill front-end clears the easy majority for almost nothing. Layer static and dynamic compaction on top and the pattern count — which is test time and cost (1.4) — is minimized without touching coverage. This is why a bloated pattern set is almost always a flow problem (missing dropping, random-fill, or compaction), not a hard design — a diagnosis that saves teams from wrongly 'accepting' huge test costs. The coverage curve the loop produces is itself a planning artifact: its fast rise shows the easy faults falling, and its flat tail localizes the hard-to-control/observe faults (5.2) where test points (Chapter 6) raise coverage far more cheaply than piling on patterns. Fault simulation also underlies diagnosis — mapping a failing pattern to the faults it detects narrows a defect — so this loop pays off in bring-up too. For the RTL/DV engineer, the flat tail is the actionable signal: it's your hard-to-test logic, and improving its testability (Chapter 6) both raises coverage and shrinks the pattern set — a win on quality and cost at once, exactly what the FSM run in 5.6 will demonstrate.

13. Engineering Checklist

• Fault-simulation dropping enabled — each pattern credits/drops all faults it detects.
• Random-fill pass first (easy faults), deterministic for the hard remainder.
• Static + dynamic compaction on — minimized pattern count (test time, 1.4).
• Read the coverage curve — stopped at the flat tail; flagged test-point candidates (Ch6).
• Verified a bloated set wasn't a flow misconfiguration before blaming the design.

14. Try Yourself

1. Given 12,480 faults, show why one-pattern-per-fault is infeasible, and how fault dropping avoids it.
2. Run the loop on paper: generate a pattern, assume it also detects 150 faults, drop all 151, repeat.
3. Add a random-fill pass clearing 80% cheaply; note deterministic ATPG only handles the remainder.
4. Apply compaction (merge/pack) to cut the final count; confirm coverage is unchanged.
5. Sketch the coverage curve (fast rise, flat tail) and mark where test points (Ch6) beat more patterns.

The loop is tool-neutral — the arithmetic is illustrative. Real generation/fault sim/compaction come from the ATPG tool. No paid tool required.

15. Interview Perspective

• Weak: "ATPG generates patterns and simulates faults."
• Good: "Generation makes a pattern per target fault; fault simulation finds what else it detects and drops those, keeping the set small."
• Senior: "ATPG's two halves make the set compact. Deterministic generation (the 5.2 search) makes one pattern for a hard target fault — it's expensive, so you use it sparingly. Fault simulation takes each pattern and credits every other fault it also detects, dropping them (one pattern kills many) — and computes the golden response. Real flows random-fill first (fault-sim to clear the easy 80% cheaply), then deterministic for the hard remainder, then static + dynamic compaction to cut the pattern count (test time, 1.4). The coverage curve rises fast then flattens — the flat tail is where test points (Ch6) beat more patterns. A bloated set is a flow bug — check dropping/random-fill/compaction."

16. Interview / Review Questions

17. Key Takeaways

• ATPG builds a compact pattern set from two cooperating halves: pattern generation (the deterministic 5.2 search makes one pattern per hard target fault) and fault simulation (finds every other fault that pattern also detects and drops them — one pattern credits many — and computes the golden response).
• Real flows random-fill first (cheap patterns + fault sim clear the easy majority), then run deterministic ATPG only on the hard remainder — because most faults are easy and only a minority need the expensive search.
• Compaction — static (merge compatible patterns) and dynamic (pack multiple faults per pattern) — shrinks the pattern count further, coverage unchanged → lower test time (1.4).
• The coverage curve rises fast then flattens (diminishing returns); the flat tail is the hard-to-control/observe logic (5.2) where test points (Ch6) beat more patterns.
• A bloated pattern set / long runtime is almost always a flow problem (missing fault dropping, random-fill, or compaction) — not a hard design. Next: 5.4 — combinational vs sequential ATPG.

18. Quick Revision

Generation & fault simulation. Two halves make a COMPACT set. GENERATION = deterministic search (5.2) → ONE pattern per hard target fault (expensive → use sparingly). FAULT SIMULATION = find ALL other faults that pattern also detects → FAULT DROPPING (one pattern credits many) + computes GOLDEN. Real flow: RANDOM-FILL first (clear easy ~80% cheaply) → deterministic for the hard remainder → COMPACTION (static merge + dynamic pack) → few patterns, high coverage (test time, 1.4). Coverage curve rises fast then FLATTENS → flat tail = hard C/O faults → test points (Ch6) beat more patterns. A bloated set = a FLOW bug (dropping/random-fill/compaction off). Next: 5.4 — combinational vs sequential ATPG.