Articles
DFT (Design for Test) Interview Questions: Scan Chains, Fault Coverage, and Testability Trade-Offs
Prepare for DFT interview questions with scan phases, a worked stuck-at fault matrix, coverage denominators, and chain-length, pin, and power trade-offs.
A chip passes its functional simulations, yet the manufacturing test leaves several internal faults undetected. Adding scan chains helps, but it does not explain which faults became detectable, which patterns are legal, or how much tester time the design needs. A strong DFT interview answer connects access, a stated fault model, observable responses, and implementation constraints.
Start with Explain timing and testability concepts. Draw one internal register, describe how to set and observe it, then explain what evidence would justify a coverage claim.
What does scan add to a functionally correct design?
Official facts: Synopsys TestMAX DFT lists scan chains, test points, compression, core wrapping, and boundary scan as test structures. Siemens describes controllability and observability limits as contributors to coverage gaps. These are vendor descriptions of test capabilities, not guarantees for an arbitrary chip.
Preparation explanation: Controllability asks whether a test can put an internal node into the value needed to activate a modeled fault. Observability asks whether the resulting difference can reach a measured output or captured state. Functional operation can require a long sequence to reach that state; scan access lets selected registers participate in a shift path.
In a conventional muxed scan arrangement, scan enable selects serial scan data during shifting and functional data during capture. Shifting loads a chosen register state; capture records the logic response; unloading exposes captured bits for comparison. The implementation and clock protocol determine the exact behavior.
Evidence boundary: This guide uses current public vendor material checked on October 6, 2026. Numerical exercises, diagnostic recommendations, and the Boolean fixture are original preparation material. No commercial ATPG tool or physical chip was run for this article.
How do shift and capture failures differ?
Official fact: Siemens' scan-chain diagnosis paper distinguishes chain tests that shift data without capture from scan tests that establish a functional state and capture a response.
Original debugging exercise: A four-cell chain receives a repeating pattern. Before diagnosing combinational logic, check whether the expected sequence emerges after the specified shift latency. Record scan input, scan output, clock edges, scan enable, reset state, and the chain order used to calculate the response.
If the sequence is corrupted during shift-only operation, investigate the scan path and protocol first. A stuck signal, wrong chain order, or shift timing problem can make a good logic block appear defective. Adding more functional capture patterns does not establish that the transport path is working.
If shifting passes but captured responses differ, inspect the loaded state, capture clocks, functional inputs, expected response, and any masked observations. Compare the actual netlist and timing assumptions with those used to generate patterns. A failure after scan reordering can be a stale mapping problem, not evidence of a newly defective gate.
Say which experiment separates those explanations. “Run ATPG again” is an action; “repeat a shift-only pattern under the same protocol and compare the first incorrect bit” is a diagnostic test with an interpretable result.
Can you calculate stuck-at coverage for a small circuit?
Original fault exercise: Consider n = a AND b and y = n OR c. Treat a, b, c, n, and y as five distinct signal sites. At each site, inject either stuck-at-0 or stuck-at-1, one fault at a time. This deliberately uncollapsed list contains ten modeled faults.
A pattern detects a fault when the faulty circuit's observed y differs from the fault-free y. Activating a fault is not sufficient: the difference must also propagate through the remaining logic.
| Input pattern abc | Detected single faults in this exercise |
|---|---|
| 000 | c stuck-at-1; n stuck-at-1; y stuck-at-1 |
| 111 | y stuck-at-0 |
| 110 | a stuck-at-0; b stuck-at-0; n stuck-at-0; y stuck-at-0 |
| 010 | a stuck-at-1; c stuck-at-1; n stuck-at-1; y stuck-at-1 |
| 100 | b stuck-at-1; c stuck-at-1; n stuck-at-1; y stuck-at-1 |
| 001 | c stuck-at-0; y stuck-at-0 |
The two patterns 000 and 111 detect four unique faults, so coverage over this stated list is 4 / 10 = 40%. Count each detected fault once, even when several patterns detect it. Enumerating all eight input combinations detects all ten in this model.
For a stuck-at-0, choose 110: the good AND output is 1, the faulty output is 0, and c=0 lets the difference reach y. Choosing 111 activates that fault at a, but c=1 forces the OR output high in both circuits. The observation is masked.
The local fixture evaluated all eight combinations and ten injections, checked the sparse and complete sets, checked two sensitization examples, and checked the scan-cycle arithmetic below. All six assertions passed in the saved local Python run. These results demonstrate the stated Boolean model; they do not estimate production defect escapes, delay-fault coverage, or an ATPG tool's reported coverage.
Why can a high coverage percentage mislead?
Official fact: TestMAX ATPG supports multiple fault models, including transition, bridging, path-delay, and cell-aware models. A stuck-at result alone therefore does not describe every test objective.
Preparation recommendation: Ask for the fault model, fault-list construction, detected count, excluded categories, and treatment of untestable or unresolved faults. Tools can report different measures; write the numerator and denominator instead of assuming that “test coverage” and “fault coverage” always mean the same calculation.
For example, a report might have 9,000 detected faults out of 10,000 listed faults, with 500 classified as untestable. 9000/10000 and 9000/9500 answer different questions. The classification must be justified before quoting the second number. Moving difficult faults out of a denominator can raise a percentage without improving detection.
Fault collapsing also changes the list by representing equivalent or dominated faults according to the tool's method. Compare reports generated under compatible modeling and classification rules. A pattern count is not a coverage denominator, and functional code coverage is not a substitute for structural fault detection.
An interview answer should name the remaining risk. “All modeled stuck-at faults were detected” can be precise. “The chip has no defects” goes beyond that evidence. Timing, analog behavior, unmodeled defect mechanisms, and test conditions require their own coverage and validation arguments.
Does a stuck-at pattern establish an at-speed test?
Original follow-up: In the ten-fault circuit, each evaluation compares static Boolean outputs. There is no delay, clock period, or launch-and-capture sequence in the fixture. A slow transition can reach the correct final value and still violate a real capture deadline. The static exercise cannot detect that failure.
For a timing-oriented test, state how the transition is launched, which clock edge captures it, what timing interval is required, and which paths are sensitized. Do not reuse a shift-frequency calculation as the capture deadline. A test protocol can shift slowly while using a different capture sequence to target timing behavior.
Likewise, a passing shift-only chain test establishes only the observations exercised under that protocol. It does not prove every capture path works at the required speed. Conversely, a capture failure does not identify a particular delay defect until competing explanations such as an incorrect expected value, reset condition, or clock sequence have been checked.
In a review, ask for the relevant pattern and waveform rather than accepting a single aggregate percentage. Explain whether the evidence concerns static logic, scan transport, or timed capture. Keeping those claims separate lets a team choose a targeted next test without treating every failure as a reason to change the whole scan architecture.
How do chain length and chain count change test time?
Original timing calculation: Assume 96 scan cells, no compression, balanced parallel chains, one capture cycle per pattern, and 100 patterns. All chains shift together. Each pattern needs the longest chain's shift length; unloading one response can overlap loading the next pattern. Include the final unload.
Under those assumptions, total cycles are P × (L + C) + L, where P is patterns, L is longest chain length, and C is capture cycles per pattern. One 96-cell chain needs 100 × (96 + 1) + 96 = 9,796 cycles. Four 24-cell chains need 100 × (24 + 1) + 24 = 2,524 cycles.
That is a cycle comparison, not a measured test-time promise. If shift and capture clocks run at different rates, calculate their durations separately. Initialization, tester setup, repeated captures, padding, compression protocols, and other test types can change the total.
A four-chain design with lengths 45, 17, 17, and 17 uses the 45-cell length for synchronized shifting. Dividing 96 by four would understate its shift cost. Explain why physical placement and domain boundaries might justify that imbalance before recommending a rebalance.
What trade-offs appear when you add chains or compression?
Official facts: Tessent ScanPro describes partitioning by clock domains, power domains, and physical clusters. Tessent TestKompress describes compressed scan patterns. These capabilities support different architectures; they do not imply that every design should maximize parallelism.
Original design comparison: More parallel chains can reduce shift cycles but require access bandwidth and routing. Compression connects a limited external interface to internal chains through additional logic. Evaluate pin limits, pattern volume, implementation cost, observation quality, and diagnostic needs together.
Do not treat compressed responses as independent, direct observations of every internal cell. Unknown values and masking can affect what information reaches the measured response. Ask where X values originate, how the chosen architecture handles them, and whether a mask removes useful observations for the faults under discussion.
Test points can improve access to difficult logic, but extra hardware has area, routing, and functional timing consequences. A targeted point supported by a coverage analysis is easier to defend than adding points indiscriminately. Measure the improvement under the same fault list and legal test constraints.
For power, Synopsys' ATPG product reference describes controlling switching during shift and capture. In the original 96-cell exercise, a shorter schedule is useful only if the chosen activity and clocks remain within the allowed test conditions. A lower shift frequency changes duration; it does not automatically solve every capture-power problem.
What evidence should you request for a coverage regression?
Original review case: Coverage falls after a clock-gating change. Compare the prior and current netlists, test protocol, constraints, chain configuration, and fault classification before declaring the new logic untestable. Find the affected hierarchy and the first category that changed.
Check whether the intended test clocks reach the relevant cells and whether reset or gating controls hold the required values in each phase. Separate a modeling mistake from an actual access limitation. Validate a proposed test-mode override against functional behavior and timing; forcing signals without a documented mode contract can create another defect.
For a power-domain change, record which blocks are powered, which isolation values apply, and which scan paths remain legal. A chain that crosses an unavailable region cannot be treated as an ordinary continuously accessible register path. Domain-aware partitioning is a design constraint, not just an organizational preference.
Close the review with a reproducible before-and-after report: same modeled objective, changed constraints listed, detected and unresolved counts, pattern and cycle costs, and implementation impact. If exclusions changed, explain them separately. The reviewer should be able to see whether the design improved or the measurement changed.