Fault Models and Coverage
How we model physical defects as testable faults
We cannot test for every possible physical imperfection directly, so we model defects as a small set of abstract faults that test tools can target. Understanding these models is the foundation of DFT.
The stuck-at model
The most common model is the stuck-at fault: a node is assumed to be permanently stuck at 0 (stuck-at-0) or stuck at 1 (stuck-at-1), regardless of what drives it. To detect a stuck-at fault you must do two things: drive the node to the opposite value, and make that node observable at an output so you can see whether it actually changed.
Controllability and observability
Those two needs have names. Controllability is how easily you can set an internal node to a chosen value from the inputs. Observability is how easily you can see an internal node value at an output. A node that is hard to control or hard to observe is hard to test, and the whole point of DFT is to make every node both controllable and observable.
Other fault models you will hear
| Fault model | What it catches |
|---|---|
| Stuck-at | Nodes permanently stuck at 0 or 1 |
| Transition (at-speed) | Nodes that switch, but too slowly |
| Bridging | Two nodes shorted together |
| Path delay | A specific path that is too slow |
Test coverage and fault coverage
Coverage measures how good your test is. Fault coverage is the percentage of modeled faults your patterns can detect. Test coverage is similar but excludes faults that are provably untestable. Production chips typically target very high stuck-at coverage, often above 99 percent, plus separate at-speed coverage for timing-related defects.
When asked why a node is hard to test, answer in terms of controllability and observability. Deep internal state that takes many cycles to set up is hard to control; logic buried far from any output is hard to observe. Scan, the next lesson, fixes both at once.