In short: Stuck-at vectors catch broken connections and dead nodes, but they miss resistive bridges between adjacent nets and slow timing paths — so production DFT adds bridging fault models (shorts) and path-delay / transition fault models (timing) to reach the defect coverage that silicon at advanced nodes actually demands.
Ask any fresh graduate to name a fault model and you will hear "stuck-at" — and nothing else. That is a problem, because in a modern 7 nm or 5 nm SoC the single stuck-at model, on its own, lets a worryingly large fraction of real silicon defects escape to the customer. Line widths are now a handful of atoms across, metal pitches are tight, and a speck of contamination between two routed wires does not kill a net outright — it leaves a resistor. This article walks through the two fault families that close that gap: bridging faults (unintended shorts between nodes) and path-delay / transition faults (nodes that switch, but too slowly).
Why stuck-at is not enough
The single stuck-at (SSA) model abstracts every defect into one of two states on a signal line: stuck-at-0 (SA0) or stuck-at-1 (SA1). It is elegant, the fault list is linear in gate count, and ATPG tools solve it in seconds. But it carries two silent assumptions that advanced silicon routinely violates: that a defect forces a fixed logic value, and that circuit timing is irrelevant. Real defects are messier. A particle landing between two adjacent metal-2 wires creates a low-ohmic bridge, not a hard tie-off. A thinned via or a high-resistance contact slows an edge instead of blocking it. Neither shows up reliably on a stuck-at pattern set.
Field data point: Industry studies (and the classic Intel analysis behind the "n-detect" movement) found that a stuck-at-only pattern set can leave hundreds of defective parts-per-million escaping test. Adding bridging and transition/path-delay patterns is what pulls DPPM from the thousands down toward single or double digits.
Bridging faults: the short-circuit model
A bridging fault models an unintended electrical connection between two nodes that should be independent. The two nodes form an aggressor–victim pair. What logic value appears at the bridge depends on the resolution behaviour:
- Wired-AND / wired-OR: the classic (bipolar-era) assumption — the shorted node resolves to the AND or OR of the two driven values.
- Dominant bridging: in CMOS the stronger driver wins. If net A has a wide driver and net B a weak one, A "dominates" B when they disagree. This is the dominant model that tools like Synopsys TetraMAX / TestMAX and Siemens Tessent support.
- Dominant-AND / Dominant-OR (4-way): a refinement that captures input-pattern-dependent behaviour of resistive bridges.
To detect a bridge you must set the two nets to opposite values (so the short can corrupt one) and propagate the corrupted node to an observable output. That is strictly harder than stuck-at: the pattern must control two nets simultaneously. Crucially, ATPG does not guess which nets are neighbours — the realistic bridge list comes from the physical layout. The place-and-route database (via an LEF/DEF or extracted-parasitic flow) tells the tool which nets are physically adjacent and over what coupling length. This is why bridging ATPG is often called layout-aware or physically-aware test.
Path-delay and transition faults: the timing models
Where bridging is about wrong value, delay models are about wrong time. A gate may compute the correct logic but take too long, so the value arrives after the capture clock edge. Two models dominate:
| Aspect | Transition fault | Path-delay fault |
|---|---|---|
| Granularity | Lumped slow-to-rise / slow-to-fall at one node | Cumulative delay along a specific gate-to-gate path |
| Fault count | ~2× nodes (tractable) | Exponential (select critical paths only) |
| Catches | Gross localized slowdowns (spot defects) | Small distributed delays summing on long paths |
| Driven by | Netlist | STA / timing report (critical + near-critical paths) |
Both require a launch–capture pair of vectors applied at functional (at-speed) frequency. The first vector sets up an initial value; the second launches a transition; the capture clock then samples whether the edge made it in time. The two ways to launch — launch-on-shift (LOS) and launch-on-capture (LOC, also called broadside) — differ in how the second vector is produced and in their timing closure demands; LOC is the more common because it avoids needing an at-speed scan-enable.
Rule of thumb: Transition-fault ATPG is your workhorse for at-speed coverage — cheap to generate and good at catching localized spot defects. Path-delay patterns are a targeted supplement aimed at the handful of critical and near-critical paths your static timing analysis flags as having the least slack.
Putting it in a real DFT flow
In production you do not pick one model — you layer them. A typical advanced-node sign-off stack runs stuck-at first for structural coverage, then transition faults for at-speed timing, then a layout-aware bridging and cell-aware pass for the hard physical defects, often with n-detect (detecting each stuck-at fault N times to incidentally cover unmodeled defects). Tools such as Synopsys TestMAX ATPG, Siemens Tessent, and Cadence Modus all read the physical layout and the SDC/timing reports to build these fault lists. The scan chains, compression (EDT / codec), and on-chip clocking you insert during DFT must all support at-speed capture for the delay models to even be applicable.
If you are building the actual silicon, the layout-awareness of these models is exactly why design-and-test co-ownership matters — teams doing full physical-design and DFT sign-off, like the engineers at Avecas VLSI design services, feed extracted neighbour data straight into the bridging fault list rather than relying on netlist-only assumptions.
For a deeper treatment of the timing side, our companion piece on the transition fault model breaks down LOS vs LOC and slow-to-rise/fall mechanics, and if you are still solidifying the basics, start with the stuck-at fault model before layering these on top.
Ready to master fault models end-to-end — stuck-at, transition, path-delay, bridging, and cell-aware ATPG on industry tools? CourseTron's DFT track walks you through real pattern generation and coverage sign-off. Explore the CourseTron DFT course → (or compare live cohorts at ChipXpert training).
Frequently asked questions
Why can't I just run more stuck-at patterns instead of adding bridging faults?
More stuck-at patterns (n-detect) help incidentally, because detecting a node repeatedly under varied conditions sometimes exercises an adjacent short. But it is indirect. A true bridging fault list derived from the layout guarantees you set the aggressor and victim to opposing values and observe the corruption — n-detect only does so by luck.
What is the difference between a transition fault and a path-delay fault?
A transition fault lumps all extra delay at a single node (slow-to-rise or slow-to-fall) and is cheap to target everywhere. A path-delay fault accumulates delay along one specific path end-to-end, so it catches small per-gate slowdowns that only matter when they sum on a long, low-slack path. You target path-delay faults selectively using critical paths from static timing analysis.
Why do bridging and path-delay ATPG need the physical layout?
Bridging ATPG needs to know which nets are physically adjacent (and for how long) to build a realistic short list — that comes from place-and-route and parasitic extraction. Path-delay ATPG needs the STA timing report to know which paths are critical. Neither can be derived from the gate-level netlist alone.
Do these models replace at-speed functional testing?
They complement it. Structural at-speed scan (transition/path-delay) is far more controllable and higher-coverage than functional patterns, but functional and system-level test still catch interaction effects and anything the structural models miss. Most high-reliability flows use both.