Skip to content
VLSIMentor

DFT · Chapter 2 · Fault Models

Why We Model Faults at All

Real physical defects are effectively infinite and analog, from metal shorts and resistive vias to open contacts, weak transistors, particles, and gate-oxide leakage, so you cannot enumerate them or write a test for each one. A fault model is the abstraction that makes test tractable: a finite, discrete, logical proxy for those defects, such as a node stuck at zero or one, that an ATPG tool can enumerate, target with patterns, and measure coverage against. It exists because pattern generation needs a countable list of things to detect and coverage needs a denominator. Crucially, coverage is measured against the model, not physical reality, which is exactly why even full fault coverage does not guarantee zero DPPM. Every model trades fidelity against tractability, and different models catch different defect classes.

Foundation13 min readDFTFault ModelFault ListATPGCoverage

Chapter 2 · Section 2.1 · Fault Models

Project thread — Chapter 1 established the economics of catching defects on the counter lot. Chapter 2 asks: what, precisely, does the tester try to detect? The answer is modeled faults — and 2.6 enumerates them on the original flip-flop.

1. Why Should I Learn This?

Every later DFT number — fault coverage, ATPG patterns, DPPM targets — is defined against a fault model. Without it, none of them mean anything.

  • Physical defects are infinite and analog → not enumerable.
  • A fault model is a finite, discrete, logical proxy ATPG can enumerate and target.
  • The fault list is coverage's denominator.
  • Coverage is vs the model, not reality → 100% coverage ≠ 0 DPPM (unmodeled defects).

2. Real Silicon Story — the '100% coverage' that still shipped escapes

A team proudly hit 100% stuck-at coverage and treated the part as 'fully tested.' Months later, field escapes appeared — parts that had passed every pattern.

The escapes were timing defects: nodes that switched correctly but too slowly (resistive vias). The stuck-at model doesn't represent slow transitions — those defects weren't in the fault list at all, so 100% coverage against that model said nothing about them. The parts passed because the tester was checking the wrong vocabulary of defects.

The fix wasn't 'more stuck-at patterns' — it was adding a transition fault model (2.3) and at-speed test to cover the defect class the first model couldn't see. Lesson: a fault model is a proxy; 100% coverage means 100% of the modeled faults, and unmodeled defect classes escape. You cover reality by covering it with multiple models, not by maxing one.

3. Factory Perspective — how each role reads a fault model

  • What the test engineer sees: the fault list and the coverage number — their job is to generate patterns that detect as many modeled faults as possible at acceptable test time. They live in the model's vocabulary.
  • What the yield engineer sees: the mapping from failing patterns → suspected physical defect classes (diagnosis). A pattern of fails hints at which real defects (shorts, opens, timing) dominate the process.
  • What the RTL/DV engineer sees: that the model is derived from their netlist — uncontrollable/unobservable logic becomes untestable faults (2.5) that cap coverage. Testability is a design property.
  • What management cares about: the model sets the coverage metric that gates signoff and DPPM commitments (1.5) — it's the number in the quality contract, and choosing too weak a model under-protects the customer.

4. Concept — from infinite physics to a finite list

The abstraction ladder:

  1. Physical defects (analog, infinite): shorts, opens, resistive vias, weak drive, leakage, particles.
  2. Fault model (logical, finite): a rule that maps a class of physical defects to an idealized logical fault — e.g. 'this node behaves as if permanently 0.'
  3. Fault list: the enumerated set of modeled faults for a specific netlist — coverage's denominator.
  4. ATPG: generates patterns that detect faults from the list (excite + propagate — 2.2).
  5. Coverage: detected / total faults in the list — a proxy for defect-catching ability.

Why a proxy works (and where it fails):

  • A good model is abstract enough to enumerate yet correlated with real defects — detecting the modeled fault tends to detect the physical defects it stands for.
  • But the correlation is imperfect: defects outside the model's vocabulary (a slow transition, a subtle bridge) are unmodeled — not in the list, so coverage is blind to them.
  • Hence the golden rule: coverage is measured against the model, not reality. 100% coverage ≠ 0 DPPM.

Fidelity vs tractability — why there are several models, not one:

  • More faithful models (bridging, path-delay) capture more defect classes but are harder to enumerate and target (layout-dependent, at-speed, many more faults).
  • So the industry uses a portfolio: stuck-at (cheap, dominant), plus transition/delay and bridging/IDDQ where DPPM demands justify the cost.
Physical defects abstracted into a fault model, enumerated into a fault list, targeted by ATPG patterns, measured as coverage against the modelPhysical defects → fault model → fault list → ATPG → coveragePhysical defects → fault model → fault list → ATPG → coverage1Physical defectsinfinite, analog — NOT enumerable2Fault MODELfinite logical proxy (e.g. stuck-at-0)3Fault LISTenumerated over the netlist — coverage denominator4ATPG patternsdetect faults from the list (excite + propagate)5Coverage (vs MODEL)detected/total in the list — blind to unmodeled defects
Figure 1 — the abstraction from physical defects to a coverage metric (representative). LEFT: real PHYSICAL defects are infinite and analog (shorts, opens, resistive vias, weak transistors, leakage) -- not enumerable. A FAULT MODEL abstracts a class of them into a finite LOGICAL proxy (e.g. node stuck-at-0). Enumerated over the netlist, the model produces a FAULT LIST (coverage's denominator). ATPG generates PATTERNS that detect list faults; COVERAGE = detected/total IN THE LIST. Key: coverage is measured against the MODEL, not reality -- so unmodeled defects escape (100% coverage != 0 DPPM).

A single physical short becomes a single logical proxy the tool can reason about:

A physical short to ground is abstracted by the stuck-at model as node stuck-at-0, which ATPG can targetabstracttargetPhysical: wire shortto gndanalog defect on siliconModel: nodestuck-at-0finite logical proxyATPG: excite to 1,propagatea pattern that would catchit12
Figure 2 — one physical defect mapped to a logical fault (representative). A metal wire SHORTED to ground is a physical defect. The stuck-at fault MODEL abstracts it as 'this node is stuck-at-0' -- a logical statement ATPG can target with an excite+propagate pattern. The proxy is not the defect; it STANDS IN FOR a whole class of defects (shorts to gnd, some opens) that make the node look permanently low. Different physical defects need different models -- one proxy cannot represent every defect.

5. Mental Model — a wanted-poster for defects

You can't photograph every criminal, so police use descriptions — 'tall, dark coat, limps.' A fault model is a wanted-poster: a finite, describable proxy for a whole class of real offenders.

  • The poster (model) is not the criminal (physical defect) — it's a useful description that lets you search systematically.
  • Catch rate (coverage) is measured against the posters you printed — if a criminal matches no poster (unmodeled defect), your 100% catch-rate on printed posters doesn't include them.
  • Different crimes need different posters — one description can't cover everyone, so you print a set (stuck-at + transition + bridging).
  • A more detailed poster catches more but is harder to print and match (fidelity vs tractability).

'100% of the wanted list' is not 'zero criminals on the street' — that gap is unmodeled defects → DPPM.

6. Working Example — a fault list for the counter

Enumerate a fault list for a few nodes of the project's 4-bit counter (stuck-at model, the default vocabulary):

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
# Fault list — REPRESENTATIVE, SIMPLIFIED, tool-neutral (stuck-at model, a few nodes of counter4):
#   each NODE contributes 2 faults: stuck-at-0 (SA0), stuck-at-1 (SA1)
  count[0]   SA0    (node behaves as permanently 0)
  count[0]   SA1    (node behaves as permanently 1)
  count[1]   SA0
  count[1]   SA1
  rst_n      SA0    (reset looks permanently asserted)
  rst_n      SA1    (reset looks permanently deasserted)
  clk-gated  SA0/SA1 ...
# Total (before collapsing) ~ 2 x (number of nodes). This LIST is coverage's denominator.
# NOTE: this list only represents STUCK-AT defects. Timing defects (slow transitions) are NOT here
#       -> they need the transition model (2.3). Shorts between nodes need bridging/IDDQ (2.4).

7. Industry Flow — where the model sits in the ASIC flow

The fault model is the hinge between the design world and the silicon-test world:

RTL to synthesis to netlist, fault model derives the fault list, ATPG generates patterns, patterns run at silicon testFault modeling in the ASIC flowFault modeling in the ASIC flow1RTL → Synthesisproduces the gate netlist2Apply fault modelderive the fault list from the netlist3ATPGgenerate patterns, measure coverage vs model4Silicon test (ATE)apply patterns → sort good/bad dies5Coverage → DPPMthe quality the part can promise (1.5)
Figure 3 — where fault modeling sits in the ASIC flow (representative). RTL -> SYNTHESIS produces the gate NETLIST. The FAULT MODEL is applied to the netlist to derive the FAULT LIST. ATPG generates PATTERNS against the list; coverage is measured vs the model. Patterns become the tester program (STIL/WGL, Ch5) applied at SILICON TEST. Upstream, RTL/DFT choices set what is testable; downstream, coverage sets the DPPM the part can promise (1.5). The model is the bridge from design to manufacturing test.

8. Debugging Session — 100% coverage but field escapes

1

A part reports 100% stuck-at coverage yet ships field escapes, and the team concludes the coverage number is lying; in fact coverage is measured against the STUCK-AT MODEL only, and the escapes are a different defect class (slow transitions) that the model does not represent -- so the fix is to add the missing fault model, not distrust coverage

COVERAGE IS VS THE MODEL, NOT REALITY — UNMODELED DEFECTS ESCAPE
Symptom

The part reports 100% stuck-at fault coverage, yet field escapes keep arriving. Someone concludes 'the coverage number is meaningless' or 'the tester is broken.'

Root Cause

Coverage is measured against the fault model you chose, not against physical reality — so 100% coverage means 100% of the modeled faults, and defects outside that model's vocabulary are simply not counted. Here the model is stuck-at, which represents nodes that are permanently 0 or 1. But the escaping defects are timing defects — nodes that switch correctly but too slowly (resistive vias, weak drive). A slow transition is not a stuck node, so it is not in the stuck-at fault list at all; the ATPG patterns never targeted it, and the coverage metric never accounted for it. The 100% is honest — it just answers a narrower question than 'is this part defect-free.' Two wrong conclusions to avoid: (1) 'coverage is lying' — no, it's measuring exactly what it claims (modeled faults), and (2) 'the tester failed' — no, the tester applied the patterns correctly; there were simply no patterns for a defect class the model doesn't represent. This is the direct, mechanical reason 100% coverage ≠ 0 DPPM (1.5).

Fix

Add the fault model that represents the escaping defect class — you cover reality with a portfolio of models, not by maxing one. For timing escapes, add the transition/delay fault model (2.3) and at-speed test, which enumerate 'slow-to-rise / slow-to-fall' faults the stuck-at list never had; for suspected shorts/leakage, add bridging/IDDQ (2.4). Then coverage is reported per model (stuck-at coverage and transition coverage), and the DPPM story (1.5) accounts for each defect class — with SLT/burn-in as insurance for whatever remains unmodeled. The principle to internalize: a fault model is a finite logical proxy for infinite physical defects; coverage is measured against the model, so 100% coverage certifies the modeled faults are testable-and-tested, never that the silicon is defect-free — real quality comes from choosing a portfolio of models that spans the defect classes your process actually produces. (Stuck-at is 2.2; transition/delay 2.3; bridging/IDDQ 2.4; untestable faults 2.5.)

9. Common Mistakes

  • Treating coverage as reality. It's coverage of the model — unmodeled defects are invisible to it.
  • Believing 100% coverage = defect-free. It means the modeled faults are covered; DPPM stays nonzero (1.5).
  • Using one model for every defect class. Stuck-at misses timing and some shorts — use a portfolio.
  • Confusing fault model with verification. Verification finds design bugs; fault models target physical defects.
  • Ignoring that the list comes from the netlist. Untestable design logic caps the achievable coverage.

10. Industry Best Practices

  • Match the model portfolio to the DPPM goal — add transition/bridging/IDDQ as the market demands (1.5).
  • Report coverage per model — never a single blended number that hides which defect classes are covered.
  • Remember the proxy boundary — plan insurance (SLT/burn-in) for unmodeled defects.
  • Feed diagnosis back — failing-pattern analysis tells you which physical defect classes dominate.
  • Treat testability as a design property — the fault list's 'hard' faults trace to RTL/DFT decisions.

11. Senior Engineer Thinking

  • Beginner: "We hit 100% coverage, so the part is fully tested."
  • Senior: "100% of which model? Stuck-at 100% says nothing about timing or bridging defects — those need their own models. Coverage is measured against the model, so I run a portfolio matched to my DPPM goal, report it per model, and keep SLT/burn-in for the unmodeled tail. The fault list is a map, not the territory."

The senior treats the model as a deliberate, bounded proxy and engineers a portfolio, never trusting one number as 'reality.'

12. Silicon Impact

The fault model is the single most load-bearing abstraction in manufacturing test — every pattern, every coverage number, every DPPM commitment (1.5) is defined relative to it. Choose the model portfolio well and the coverage metric correlates with real defect-catching, so coverage closure (Chapter 6) genuinely lowers escapes. Choose it poorly — a single model where the process produces multiple defect classes — and you get the most dangerous failure in DFT: a confident 100% coverage number that quietly ignores a whole class of escaping defects, exactly the trap in the story. For the RTL/DV engineer, the impact is that the fault list is generated from your netlist, so testability is a design property you control: uncontrollable/unobservable logic becomes untestable faults (2.5) that cap what any model can achieve. And for the whole team, internalizing 'coverage is vs the model, not reality' is what keeps the DPPM story honest — it's why zero-defect markets pair high coverage with insurance for the unmodeled tail. Master this abstraction and the rest of the chapter — stuck-at, transition, bridging/IDDQ, untestable — becomes a toolkit of proxies you deploy deliberately; miss it and you'll trust a number that was never measuring what you thought.

13. Engineering Checklist

  • Chose a model portfolio matched to the defect classes and DPPM goal.
  • Reported coverage per model, not one blended figure.
  • Documented the proxy boundary and planned insurance for unmodeled defects.
  • Confirmed the fault list is derived from the netlist and reviewed hard/untestable faults (2.5).
  • Kept fault modeling (defects) distinct from verification (bugs).

14. Try Yourself

  1. For the counter, enumerate the stuck-at fault list for 3–4 nodes (2 faults each). Note it's the coverage denominator.
  2. Add a slow-to-rise defect on one node — confirm it appears in no stuck-at fault → it's unmodeled by that model.
  3. Name which model you'd add to represent it (transition, 2.3) and why 100% stuck-at wouldn't catch it.
  4. Write one sentence explaining why 100% coverage ≠ 0 DPPM, using 'model vs reality.'
  5. Identify one uncontrollable/unobservable node in the counter and predict it becomes a hard/untestable fault (2.5).

The fault list and reasoning are tool-neutral — a paper enumeration suffices. Real fault lists come from any ATPG flow (Chapters 5–6). No paid tool required.

15. Interview Perspective

  • Weak: "A fault model is a way to describe faults in a chip."
  • Good: "A fault model is a finite logical abstraction of physical defects that ATPG can target, like stuck-at."
  • Senior: "Physical defects are infinite and analog, so we abstract them into a finite, discrete logical proxy — a fault model — that ATPG can enumerate (the fault list), target with patterns, and measure coverage against. The catch is that coverage is measured against the model, not reality, so 100% coverage means 100% of the modeled faults — unmodeled defect classes still escape, which is why it isn't 0 DPPM. Because model fidelity trades against tractability, we run a portfolio — stuck-at plus transition and bridging/IDDQ where DPPM demands — and keep SLT/burn-in for the unmodeled tail."

16. Interview / Review Questions

17. Key Takeaways

  • Physical defects are effectively infinite and analog (shorts, opens, resistive vias, weak drive, leakage) — not enumerable, so you can't write a test per defect.
  • A fault model is a finite, discrete, logical proxy for physical defects that ATPG can enumerate (the fault list), target with patterns, and measure coverage against.
  • The fault list — derived from the netlist — is the denominator of every coverage number; uncontrollable/unobservable design logic becomes untestable faults (2.5) that cap coverage.
  • Coverage is measured against the model, not reality — so 100% coverage means 100% of the modeled faults, and unmodeled defects escape (100% coverage ≠ 0 DPPM, 1.5).
  • Model fidelity trades against tractability, so the industry uses a portfolio — stuck-at (2.2), transition/delay (2.3), bridging/IDDQ (2.4) — matched to the defect classes and DPPM goal. Next: 2.2 — the stuck-at fault, the workhorse model.

18. Quick Revision

Why model faults (Ch2 opener). Physical defects = infinite + analog → not enumerable. FAULT MODEL = finite, discrete, LOGICAL proxy (e.g. stuck-at-0) that ATPG can enumerate (the FAULT LIST, coverage's denominator), target with patterns, and measure coverage against. Flow: netlist → fault model → fault list → ATPG → coverage → tester. Golden rule: coverage is vs the MODEL, not reality → 100% coverage ≠ 0 DPPM (unmodeled defects escape). Fidelity vs tractability → use a portfolio (stuck-at + transition + bridging/IDDQ) matched to the DPPM goal. Next: 2.2 — stuck-at faults.