DFT Interview Questions: Scan, ATPG, and Fault Coverage

Someone hands you a report that says one block has 82 percent stuck-at coverage while the rest of the chip is above 97. What do you do first? Most DFT interviews eventually get to a question like that, because it shows whether you understand the vocabulary or just recognize it.

This guide leans on two Semiconductor Engineering articles, a Corelis boundary scan tutorial, a PubMed Central paper on memory test and repair, and some training course pages. The practice prompts are ours, not questions reported from any employer.

Scan, ATPG, and what the tool actually knows

In scan design, flip-flops are replaced with scan cells that can be linked into chains. In test mode the chains behave like shift registers. The tester shifts a pattern in, the design captures the response during a functional clock, and the response shifts out while the next pattern shifts in. The Semiconductor Engineering overview adds a useful detail: the test software does not need to understand what the logic does, only what each scan cell can control and observe.

ATPG (automatic test pattern generation) builds those patterns from a fault model. The simplest is stuck-at: each node is checked for being stuck at 0 or 1, which is a static test that does not depend on speed. Transition faults are dynamic. Each node can be slow to rise or slow to fall, so you need a launch and a capture at functional speed. One course page describes two launch styles, launch-on-capture and launch-on-shift, with different coverage and hold risk. Treat its ranges as one training site's numbers.

A good answer to "why not just use stuck-at patterns?" is that a slow clock gives a late signal time to settle, so a delay defect can look healthy.

What does a fault coverage number actually mean?

Fault coverage is, roughly, detected faults over total faults. Interviewers like to probe what sits in that denominator. Untestable faults, tied logic, blackboxes, and memories change the story. High stuck-at coverage also says little about delay defects.

You will see "95 percent" quoted often. The Semiconductor Engineering overview calls 95 percent or more typical, and one training site calls it a tapeout minimum. Those are not standards. Targets come from your product and customer, so say that instead of reciting a number.

Our static timing analysis guide covers the timing vocabulary, and the DFT versus design engineer comparison explains where the role sits.

Compression, memory test, and JTAG

Scan compression exists because tester time and pin count cost money. A decompressor on chip expands a small amount of tester data across many short internal chains, and a compactor folds the outputs back down. One course page defines the ratio as internal chains divided by tester channels, so 512 chains on 16 channels is 32 to 1. It also notes that unknown values (X) entering the compactor can corrupt the result, which is why X handling comes up. That page calls its savings figures illustrative, so use the mechanism, not the percentages.

Memory is a different problem. A paper on memory test and repair says embedded memory takes roughly 95 percent of area in recent SoCs, and that a built-in self-test controller runs March-style algorithms, writing and reading patterns in ascending and descending address order. Failures can feed a repair block that swaps in spare rows or columns. Its coverage claims come from the authors' own simulation. Our memory design interview guide covers the memory side.

JTAG (IEEE 1149.1) is mostly a board-level idea. Per the Corelis tutorial, the test access port uses TCK, TMS, TDI, and TDO, and the standard requires EXTEST, SAMPLE/PRELOAD, and BYPASS. Know that it tests interconnects between chips, and know its limits: every device in the chain needs a compliant port, and pins not on the chain stay untested.

Why does power during test matter?

This question connects DFT to physical design. The Semiconductor Engineering article says test power can run well above mission-mode power, and quotes an Intel engineer saying capture is the dangerous phase because many flops switch within one or two fast cycles. A course page makes the opposite emphasis, flagging shift power. Be ready to explain both.

Consequences include IR drop that fails a good die for reasons that would never occur in the field, and local heating at wafer sort. Mitigations the article lists include testing cores in groups, gating scan data away from functional logic, and slowing the clock for the heaviest vectors. Most cost test time or equipment. Our guides to power integrity and low power design cover the surrounding concepts.

A study table

Topic	What the sources say	Practice prompt
Scan	Chains shift in, capture, shift out	Walk through one pattern from tester to response
Stuck-at vs transition	Static test versus launch and capture at speed	Why can a delay defect pass slow patterns?
Coverage	Detected over total faults, depends on the model	What belongs in the denominator?
Compression	Decompressor and compactor, X values can corrupt results	What goes wrong if an X reaches the compactor?
MBIST	March algorithms, optional repair with spares	What would you check about the memory first?
JTAG	Four-wire port, three required instructions	What can boundary scan test that scan cannot?
Test power	Capture and shift both matter, IR drop can fail good parts	How would you lower power without losing coverage?

An illustrative scenario: one weak block

Say a block reports 82 percent stuck-at coverage. There is no single correct answer, but a sound order might be:

1. Ask what the fault model and denominator are, and whether the number counts untestable faults.
2. Check the ATPG log for why faults are not detected, such as constraints, blocked clocks, or uncontrolled resets.
3. Look for logic that scan cannot reach: blackboxes, analog macros, or memories without bypass.
4. Test one hypothesis, such as a wrong test-mode constraint, and rerun.
5. Report what improved, what remains, and what needs a design change versus a waiver.

If you have not run ATPG, say so and describe a coursework equivalent. Our guide to explaining past projects can help, and the phone screen guide shows how early rounds are framed. For the work after silicon arrives, see pre-silicon verification versus post-silicon validation and our upcoming comparison of silicon validation and product test engineers.

When you are ready to say it out loud, book a mock interview on MockVise and walk through the scenario with someone who will interrupt you.

Sources: Semiconductor Engineering (scan test), Semiconductor Engineering (test power), Corelis, PubMed Central (memory test and repair), Ecrionix DFT course, day 3, Ecrionix DFT course, day 5, Ecrionix DFT overview. This article is general technical preparation guidance, not an official interview process or reported company questions. Training site figures are illustrative and coverage targets vary by product and customer, so confirm details with your recruiter and your own tool documentation. MockVise is not affiliated with or endorsed by Semiconductor Engineering, Corelis, Ecrionix, or the authors of the cited paper.

FAQ

Q: What is the difference between stuck-at and transition faults? Stuck-at faults check each node for being stuck at 0 or 1 and are a static test. Transition faults are dynamic and need a launch and a capture at functional speed.

Q: Is 95 percent fault coverage a standard target? No. The post notes that sources call 95 percent typical or a tapeout minimum, but those are not standards. Targets come from your product and customer.

Q: What does JTAG test, and what are its limits? JTAG (IEEE 1149.1) is mostly a board-level idea that tests interconnects between chips. Every device in the chain needs a compliant port, and pins not on the chain stay untested.

Q: What should I do if I have not run ATPG before an interview? Say so, and describe a coursework equivalent instead of implying experience you do not have.