Design for Test (DFT) Interview Guide: Scan, ATPG, MBIST & JTAG Interview Prep

DFT techniques compared: what each tests, the fault model or method it uses, and its cost

Frequently asked questions

What is Design for Test (DFT)?

Design for Test (DFT) is the practice of adding dedicated logic and structures to a chip so that a tester can detect manufacturing defects on every fabricated die. The core problem is that internal nodes of a large chip have poor controllability and observability from the primary pins alone, so screening defects functionally would be slow and incomplete. Internal scan chains are the structure that makes internal flop state controllable and observable, which lets automatic test pattern generation reach high defect coverage at acceptable tester time; on-chip memory test (MBIST) handles dense embedded memories with their own self-test logic. Boundary scan (IEEE 1149.1) is different in kind: it controls and observes the I/O boundary cells and tests board and package interconnect through the test access port (TAP), so it is not an internal-state DFT method. The key interview framing is that DFT targets physical manufacturing defects, not design bugs.

What is the difference between DFT and functional verification?

They answer different questions. Functional verification asks "is the design correct?" and runs before tape-out using simulation, formal methods, and emulation against the specification. DFT and manufacturing test ask "was this particular die built correctly?" and run on automated test equipment after fabrication, on every unit. A design can be functionally perfect and still produce a die with a stuck-at fault from a fabrication defect. Verification catches logic errors; DFT catches silicon defects like opens, shorts, and slow transistors. Conflating the two is one of the most common interview mistakes.

How does scan design work?

Scan design replaces ordinary flip-flops with scan flip-flops that have an extra test input and a mode select, then chains them into one or more scan chains that behave like shift registers in test mode. Testing alternates two operations: scan shift, where a test pattern is clocked serially into all scan flops while the previous response is shifted out, and capture, where the chip runs for one (or a few) functional clock cycles so the combinational logic result is latched back into the same flops. Shifting that captured response out and comparing it against the expected value reveals defects. Scan turns a hard sequential-test problem into a largely combinational one, though it does not remove sequential concerns entirely: launch and capture timing, multiple clock domains, X-sources, and any non-scan flops still introduce sequential behavior that the patterns and clocking must account for.

What is ATPG and what fault models does it use?

ATPG (Automatic Test Pattern Generation) is the EDA process that algorithmically generates the input patterns and expected responses used to detect defects, working against an abstract fault model rather than every physical defect. The classic model is stuck-at, where a node is held permanently at 0 or 1. Transition (at-speed or delay) faults model nodes that switch too slowly to meet timing and require launch-and-capture patterns run at functional speed. Other models include bridging faults (unintended shorts between nodes) and path delay faults (cumulative delay along a critical path). ATPG quality is reported as fault coverage or test coverage, the fraction of modeled faults the pattern set can detect.

What is the difference between stuck-at and at-speed (transition) faults?

A stuck-at fault models a node permanently tied to 0 or 1 and is detected with static patterns that do not depend on timing, so the tester can apply them slowly. A transition or at-speed fault models a defect that lets a node eventually reach the right value but too late to meet the clock period, so it only shows up when the circuit runs at functional speed. Detecting transition faults requires a launch-then-capture sequence at speed, which is more demanding on the tester and on clock control. Many timing-related defects escape a stuck-at-only test set, which is why modern flows run both.

What is MBIST and why use it for on-chip memories?

MBIST (Memory Built-In Self-Test) is dedicated on-chip logic that tests embedded memories by generating memory test sequences and checking the read-back internally. March algorithms are RAM/SRAM-oriented, built from controlled read and write sequences that catch cell, address, and coupling faults; ROMs hold fixed contents and cannot be written, so they are tested with different methods such as a signature or checksum read rather than March, so the two should not be lumped under March. Embedded memories are dense, high-defect-density structures with limited external access, so external pattern-based testing through scan is inefficient for them. MBIST applies the patterns at speed from inside the chip, reports pass/fail, and often supports repair with redundant rows or columns. Skipping MBIST and assuming scan covers on-chip memory is a frequent interview gap.

What is boundary scan (JTAG) used for?

Boundary scan, standardized as IEEE 1149.1 and commonly called JTAG, places test cells around the chip pins so a tester can drive and observe pins through a serial test access port (TAP) without physical probes. Its primary use is board-level interconnect test: detecting opens and shorts in solder joints and traces between chips after assembly. The same TAP is widely reused for device configuration, debug, and accessing internal scan and BIST infrastructure. In interviews, place it at the board and package level, distinct from internal scan testing of the core logic.

Does DFT have a cost, and is 100% coverage realistic?

Yes. Scan flops are larger than plain flops, scan chains and test logic add area and routing, and test modes can affect timing closure and power. Test time on automated test equipment is directly tied to per-unit cost, so pattern count matters, which is why scan compression (e.g. EDT-style) is used to shrink pattern volume. Reaching very high coverage costs increasing pattern count for diminishing returns, and some faults are untestable by construction. Treating coverage as free, or expecting an easy 100%, signals inexperience; engineers reason about the coverage-versus-cost trade-off explicitly.

What does a strong versus weak DFT answer sound like?

A weak answer conflates DFT with functional verification, treating defect screening as if it were checking design correctness, or assumes ATPG means only stuck-at patterns. A strong answer keeps the two separate: DFT screens physical manufacturing defects on every die, while verification proves the design is correct before tape-out. The strong candidate names the fault models and what each catches, stuck-at for nodes held at a constant value, transition or at-speed for nodes that switch too slowly, bridging for unintended shorts, and path-delay for cumulative delay along a critical path, and then frames coverage as a deliberate area and test-time trade-off rather than a number to push to 100%.

How should I prepare for a DFT interview?

Drill the moves an interviewer actually probes. Explain launch-on-shift versus launch-on-capture for at-speed transition test and when each applies. Estimate the scan test-time impact of adding more chains, reasoning about shift cycles, pattern count, and tester time. Walk through debugging a low-coverage report, separating untestable faults that no pattern can detect by construction from aborted faults the tool gave up on within its effort limit. Finally, decide MBIST versus scan for an on-chip memory and justify why dense embedded memory gets at-speed March-based self-test instead of external scan patterns.

Related topics