DFT

Fault simulation

By CourseTron Team ·  7 min read ·  Updated Oct 2026 💬 𝕏 in f
Table of Contents
    ? Print / Save as PDF

    In short: Fault simulation grades a set of test patterns against a fault list (usually stuck-at) by comparing good-machine and faulty-machine responses, using fault dropping and parallel/concurrent algorithms to compute test coverage efficiently.

    Automatic Test Pattern Generation (ATPG) tells you a pattern can detect a fault. Fault simulation tells you what a given set of patterns actually detects, how much, and which faults slip through. In a modern DFT flow these two tools work in tandem: the ATPG engine generates a pattern, the embedded fault simulator grades it against the whole fault list, drops everything that pattern caught, and the engine moves on to what remains. Understanding the grading mechanics is one of the most common DFT interview topics, so let us walk through it concretely.

    What a fault simulator actually computes

    Start from a fault list. For a design with N fault sites, the classic single stuck-at model gives up to 2N faults (stuck-at-0 and stuck-at-1 per node), collapsed down by equivalence and dominance to roughly 1.1–1.3×N after fault collapsing. If you are hazy on the model itself, read our primer on the stuck-at fault model first.

    The simulator runs each test pattern through two virtual copies of the circuit: the good machine (fault-free) and a faulty machine with one fault injected. A fault is detected by a pattern when the two machines produce different values at an observable output (a primary output or a scan flop that gets shifted out). The job is to find, for every fault, at least one pattern where that divergence reaches an observe point.

    Pattern P is applied to both copies GOOD machine output = 1 0 1 1 FAULTY (n3 s-a-0) output = 1 0 0 1 XOR compare bit 3 differs: DETECTED CourseTron · coursetron.com
    A fault is detected when good and faulty responses diverge at an observable output.

    Fault dropping: why it keeps simulation tractable

    A naive simulator would keep testing every fault against every pattern, even faults already proven detectable. Fault dropping removes a fault from the active list the moment any pattern detects it, because for coverage you only need a single detection. On large designs this is the difference between hours and days: by pattern 200 of a 2,000-pattern scan set, 85–95% of faults are already dropped, so each later pattern simulates a shrinking list.

    Fault dropping is a coverage-grading optimization. For n-detect or small-delay-defect work you deliberately disable dropping (or set a detect count like N=5) so you keep counting detections past the first — trading runtime for defect-screening quality.

    Active fault count as patterns are graded Grey track = full fault list; red = faults still active (illustrative) patterns P1 P50 P500 CourseTron · coursetron.com
    Each pattern (blue) sweeps the list; detected faults are dropped, so the remaining bars shrink fast.

    Serial vs. parallel vs. concurrent algorithms

    How the simulator injects and propagates faults defines its class, and each trades memory for speed differently.

    • Serial: inject one fault, simulate the whole pattern set, compare to the good machine, repeat. Simplest and exact, but cost is O(faults × patterns × gates) — far too slow beyond toy circuits.
    • Parallel: exploit the machine word. On a 64-bit host, one logic value occupies one bit position, so a single logic operation evaluates 64 circuit copies at once — typically the good machine plus 63 faulty machines. Best for a fixed, modest set of faults per pass.
    • Deductive: carries a fault list on every signal line and deduces, in one good-machine pass, the set of faults that produce an error there. One pass, but set bookkeeping is memory-hungry.
    • Concurrent: the industry workhorse. It simulates only the faulty machines where they diverge from the good machine, dynamically creating and removing fault "copies" line by line. This event-driven locality is why it dominates production tools.
    AlgorithmParallelismMemoryTypical use
    SerialNoneLowestReference / teaching
    ParallelWord-width (e.g. 64)LowSmall fault batches
    DeductiveAll faults, 1 passHighCombinational blocks
    ConcurrentActive divergences onlyMedium–HighProduction ATPG grading

    Commercial tools — Synopsys TetraMAX/TestMAX, Siemens EDA Tessent FastScan, and Cadence Modus — embed concurrent or hybrid fault simulators directly inside the ATPG loop so grading and generation share one in-memory model.

    Measuring coverage: the numbers that matter

    Two metrics are reported and they are not the same:

    • Test coverage = detected / (total faults − undetectable faults). This is the number you quote in a test spec, because it excludes faults ATPG proved can never be tested (e.g. redundant logic, tied nets).
    • Fault coverage = detected / total faults, including the untestable ones — a stricter, usually lower figure.

    Faults also carry ATPG classes: DT (detected), PT (possibly/potentially detected, usually weighted at 50%), UD/AU (undetectable, ATPG-untestable), ND (not detected). A production stuck-at sign-off typically targets 99%+ test coverage; transition-fault coverage runs lower, often 90–95%, because timing-aware patterns are harder to justify. A worked example: 1,000,000 collapsed faults, 10,000 proven redundant, 985,000 detected → test coverage = 985,000 / 990,000 = 99.49%, while fault coverage = 985,000 / 1,000,000 = 98.5%.

    Worked example: 1,000,000 collapsed faults Total faults = 1,000,000 Detected: 985,000 Proven redundant (undetectable): 10,000 Not detected: 5,000 Test coverage = 985,000 / 990,000 = 99.49% Fault coverage = 985,000 / 1,000,000 = 98.5% CourseTron · coursetron.com
    Test coverage excludes proven-redundant faults from the denominator; fault coverage does not.

    Where fault simulation fits the DFT flow

    Beyond grading ATPG patterns, fault simulation is how you measure the value of functional or system-level patterns that ATPG did not create — e.g. grading a burn-in sequence or a BIST signature. It is also central to test pattern compaction, where you fault-simulate to confirm a smaller reordered set still hits the same coverage before dropping patterns. Teams building silicon test programs at design-services houses like Avecas VLSI design services lean on exactly this loop to trade pattern count against tester time.

    Want hands-on labs grading real scan patterns in TestMAX and Tessent? Explore the DFT track on our CourseTron courses page.

    Frequently asked questions

    Why use fault simulation if ATPG already reports coverage?

    ATPG reports coverage for patterns it generated. Fault simulation grades any arbitrary pattern set — functional vectors, legacy patterns, BIST — against the fault list, which ATPG cannot do on its own.

    What is the difference between fault dropping on and off?

    With dropping on, a fault leaves the active list after its first detection — fastest for coverage. With it off (n-detect), the simulator keeps counting detections, which improves defect screening for bridging and small-delay defects at the cost of runtime.

    Why is concurrent fault simulation preferred in industry?

    It simulates faulty machines only on the lines where they actually diverge from the good machine, so work scales with active fault effects rather than with the full fault list — giving the best speed/memory balance on large designs.

    What coverage number should a chip target?

    Single stuck-at sign-off usually targets 99%+ test coverage; transition/at-speed coverage is commonly 90–95%. The exact threshold is set by the quality (DPPM) goal in the test spec.

    Advertisement