DFT & Scan-Chain Readiness for RTL

Design for test (DFT) is the work that makes a chip testable on an ATE after it is fabricated. The dominant technique is scan: every flop in the design is stitched into one or more shift registers — the scan chains — so that a tester can shift an arbitrary state in, pulse the clock once to capture, and shift the result out. Automatic test pattern generation (ATPG) then produces the vectors that exercise manufacturing faults. None of that happens in your RTL, but your RTL decides how well it will go. A handful of register-transfer habits quietly cap the coverage you can ever reach, and most of them survive a clean lint pass and a green simulation. This page explains the scan rules that matter at the RTL stage, and what structural DFT-readiness evidence can and cannot tell you.

Controllability and observability

The whole point of scan is to make every state element both controllable (the tester can set it to a known value) and observable (the tester can read it back). A fault is only testable if you can drive a known value to its site and propagate the effect to a place you can observe. Scan gives you that for free on flops that join a chain. The problems start with the logic that sits off the chain, or with flops the chain cannot fully control. When a node is neither controllable nor observable through scan, the faults behind it are simply untestable, and the coverage number drops without any single dramatic error — it just leaks.

Resetless state

A flop with no controllable reset or set powers up to an unknown value. Functionally that may be fine — plenty of datapath registers do not need a reset — but for test it means the tester cannot force that flop to a known state at the start of a pattern except by justifying a value through surrounding logic, which is not always possible. The unknown propagates as an X through ATPG and blocks fault detection downstream. The RTL fix is to give every state element a scan-controllable reset, or to ensure it is genuinely part of a scan chain so the shift operation controls it. A resetless flop that is also off the chain is the worst case: it is neither initialized nor controlled.

Mixed-edge scan domains

Scan chains shift on a single active clock edge. When a design mixes rising-edge and falling-edge flops and the scan tool stitches them into one chain, the shift path can race: a falling-edge flop downstream of a rising-edge flop may re-sample its predecessor within the same scan period and corrupt the shifted value. Scan-insertion tools handle this by ordering the chain and inserting lockup latches, but the RTL that casually mixes edges on what will become one domain is what creates the hazard. Keeping clock edges consistent within a domain — or being deliberate about where edges change — is the cleaner starting point.

// Two state elements that would land on one scan domain but clock on
// OPPOSITE edges. Without a lockup latch between them, the shift path
// races: the negedge flop can re-sample the posedge flop in the same
// scan period and corrupt the shifted-out value.
module mixed_edge_scan (
  input  logic clk,
  input  logic rst_n,
  input  logic d,
  output logic q
);
  logic stage_p;  // captured on the rising edge
  logic stage_n;  // captured on the falling edge -- edge mixing

  always_ff @(posedge clk or negedge rst_n)
    if (!rst_n) stage_p <= 1'b0;
    else        stage_p <= d;

  // Falling-edge flop downstream of a rising-edge flop: a scan-shift hazard.
  always_ff @(negedge clk or negedge rst_n)
    if (!rst_n) stage_n <= 1'b0;
    else        stage_n <= stage_p;

  assign q = stage_n;
endmodule

Lockup latches

A lockup latch is the standard fix for a clock-boundary hazard inside a scan chain. It is a level-sensitive latch placed between two scan cells that are clocked differently — opposite edges, or skewed clocks — and it holds the shifted value stable across the boundary so the receiving cell samples the previous value, not a value that is moving underneath it. Lockup latches are inserted during scan insertion, not written in RTL, but a design that minimizes unnecessary edge mixing and clock-domain hopping on the future scan path needs fewer of them and is easier to close. Note that a lockup latch is intentional and test-specific; it is the opposite of an accidental inferred latch in functional logic, which is a bug.

Async set/reset on the scan path

Asynchronous set and reset are convenient functionally, but on a scan flop they are a liability. During shift, an async reset or set that is not held in its inactive state can fire mid-pattern and overwrite the value you were trying to shift, destroying controllability for that cell. DFT flows normally gate or hold async controls inactive in test mode, but for that to work the async source has to be controllable in the first place — an async reset driven by uncontrolled internal logic cannot be safely held. The same asynchronous-reset structure that creates reset-domain-crossing hazards also creates scan headaches, which is why reset structure is worth getting right early.

Clock domains on the scan path

Multi-clock designs do not get one giant scan chain; they get a chain per clock domain, with lockup latches and careful ordering wherever a chain crosses a clock boundary. A design that already has clean, well-identified clock domains — the same discipline that keeps clock domain crossings safe — is far easier to scan-insert than one where domains are tangled. Uncontrolled clock gating is a related trap: if a gated clock cannot be forced on in test mode, the flops behind it never shift, and their faults go untested. Test-aware clock gating cells solve this, but only if the enable is controllable.

What structural DFT-readiness evidence can and cannot tell you

A structural readiness pass reads your RTL and flags the constructs above — resetless flops, mixed-edge flops that would share a scan domain, async set/reset reaching scan-controlled state, and uncontrolled clock gating — with the file and line, before you ever run synthesis or scan insertion. That is genuinely useful: it catches the cheap-to-fix RTL habits that otherwise surface as low coverage weeks later, when fixing them is expensive.

What it cannot do is measure test coverage or sign off DFT. It does not insert scan chains, order them, place lockup latches, generate ATPG patterns, or report stuck-at or transition fault coverage — that is the job of a commercial scan-insertion and ATPG flow running on the gate-level netlist. Structural readiness is a bounded, pre-signoff view of your RTL: it tells you where you are likely to lose testability and why, and it is honest about the constructs it cannot see. It does not replace an ATPG or DFT signoff tool, and a clean readiness report is not a coverage number.

How ChipVerify checks this

ChipVerify AI runs structural DFT-readiness analysis on your RTL: it identifies state elements without a controllable reset, posedge and negedge flops that would mix on one scan domain, and async set/reset reaching scan-controlled paths, and it reports each with file-and-line evidence. This is pre-signoff structural evidence — bounded analysis that names scan-readiness risks early — not scan insertion, not ATPG, and not a foundry or DFT signoff.

FAQ

Related reading

• Reset domain crossing — the reset structure that also drives scan headaches.
• Inferred latches in Verilog — the accidental latch a lockup latch is not.
• Clock domain crossing — clean domains make scan chains far easier to insert.
• Tapeout readiness — where DFT readiness sits among the pre-cut gates.