Fault Models
Introduction
Fault models describe the structural defects that ATPG, LBIST, and MBIST must detect. They provide an abstract representation of how real silicon defects manifest at the logic or memory level, enabling systematic test generation and measurable coverage.
Why Fault Models Matter
- Define ATPG targets — the fault model determines which faults patterns must detect.
- Determine diagnostic coverage — safety metrics depend on the assumed fault universe.
- Map directly to FMEDA assumptions — each fault model corresponds to a failure mode category.
- Influence FIT contribution — the completeness of the fault model affects residual risk.
Common Fault Models
Stuck‑at Faults
A signal is permanently stuck at logic 0 or logic 1.
Used as the baseline model for ATPG and LBIST.
Transition Faults
A signal fails to make a rising or falling transition within the required time.
Captures slow‑to‑rise and slow‑to‑fall defects.
Bridging Faults
Two nets become electrically shorted.
Can cause wired‑AND, wired‑OR, or dominant‑driver behavior.
Path Delay Faults
A specific timing path violates its delay constraint.
Targets distributed delay defects not captured by simple transition faults.
Open / Short Faults
Physical opens or shorts in interconnects or vias.
Mapped to stuck‑at, bridging, or delay behavior depending on context.
Memory‑Specific Faults
- Coupling faults — one cell influences another.
- Retention faults — a cell cannot hold its value over time.
- Address decoder faults — wrong cell accessed.
- Read disturb faults — repeated reads corrupt the cell.
These are the basis for March algorithms and MBIST coverage.
Safety Connection
Coverage Metrics Depend on Fault Models
Diagnostic coverage (DC), SPFM, and LFM are computed relative to the assumed fault universe.
A weak or incomplete fault model → artificially inflated coverage.
FMEDA Uses Fault Model Mapping
Each structural fault model maps to a failure mode category (safe, detected, latent).
The mapping must be justified and consistent with the test strategy.
Safety Case Requires Justification
ISO 26262 requires demonstrating that:
- the chosen fault models are appropriate
- the test strategy covers them
- residual faults are acceptable for the ASIL level
This ties fault models directly to the safety argument.
Examples and Diagrams
Figure 1: Example of stuck‑at vs transition detection
Comparison between static stuck‑at faults and dynamic transition faults. Stuck‑at breaks logic correctness; transition faults break timing correctness.
Figure 2: Illustration of bridging behavior
This model captures the essential behavior of a bridging fault without assuming wired-AND, wired-OR, or driver dominance, making it suitable for technology‑independent test analysis.
Figure 3: Memory coupling example (inversion, idempotent)
Coupling faults model unwanted interactions between two 1‑bit memory cells. A write operation on the aggressor activates the fault, causing the victim bit to toggle (inversion coupling) or to be forced to a fixed value (idempotent coupling).
Table 1: Path‑Delay vs Transition Fault — Comparative Table
| Aspect | Transition Fault | Path‑Delay Fault |
|---|---|---|
| Fault model | Excessive delay on a single node | Excessive delay accumulated along an entire path |
| Types | Slow‑to‑rise (0→1), Slow‑to‑fall (1→0) | Robust, Non‑robust, Functional path delay |
| Activation | Apply a transition on the target node | Apply a transition that propagates through the path |
| Observation | Check if transition reaches next stage in time | Check if transition reaches the path endpoint in time |
| Delay distribution | Localized at one point | Distributed across multiple gates/interconnects |
| Physical realism | Medium | High |
| Test cost | Low | High |
| Defects detected | Local gate defects, local loading issues | Crosstalk, IR‑drop, aging, process variation, etc. |
| Coverage | Limited (misses distributed delays) | High (captures full‑path timing violations) |
Figure 4: Path delay vs transition fault comparison
A transition fault models excessive delay on a single node (slow‑to‑rise or slow‑to‑fall), while a path‑delay fault models excessive delay accumulated along an entire combinational path. Transition faults are easier to test but provide limited coverage; path‑delay faults are more realistic for distributed timing issues but require activating and observing complete paths.
