Debugging Scan-Chain Failures

Chapter 13 · Section 13.2 · DFT Debug Methodology

Project thread — the mini-SoC's scan chain: flush it first, read the signature, localize the break by counting. A good flush licenses the pattern debug of 13.3.

1. Why Should I Learn This?

Scan-chain debug is the first and most leverage-rich debug — a dead chain fails every pattern, so flushing first saves you from chasing phantom logic bugs.

• The flush test: shift a known pattern in, observe it out (delayed) — In=Out = GOOD, mismatch = BROKEN.
• Signatures: stuck = constant out; open = downstream dead; timing = fails fast / passes slow (hold, 12.2); clock/reset = looks like a break.
• Localize by counting — the cell position of the break maps to a physical cell/net (last-good cell).
• A good flush is the license to debug patterns — fix the chain first, or everything else is noise.

2. Real Silicon Story — three days chasing a bug that wasn't there

A team saw every scan pattern miscompare on one chain of a new part. They assumed a logic defect and spent three days debugging individual patterns, poring over failing bits and ATPG values.

The chain was broken. A 30-second flush test — shift 0011… in, watch the output — would have shown a constant output (the chain was stuck), meaning no pattern could ever pass and the pattern debug was pointless. When they finally flushed, they counted to the stuck cell and found the cause: a clock-gating cell whose shift clock enable was left OFF in shift mode (11.x), so that cell never clocked and held its value — killing the chain from that point. They fixed the shift-clock enable (a 12.5 shift-run issue), the flush passed, and the patterns then debugged normally (most passed). Lesson: flush first. A broken chain fails every pattern, so structure before function (13.1) is not optional — a good flush is the license to debug patterns, and localization is just counting to the cell where the flush breaks.

3. Factory Perspective — chain debug through each lens

• What the test/DFT engineer sees: the flush test as step zero — read the signature (stuck/open/timing), localize by counting, and only then debug patterns.
• What the physical engineer sees: the chain route/order and the cell the count points to — an open/short or a clock issue at a specific instance.
• What the STA engineer sees: the shift-mode timing (a timing chain = a hold violation, 12.2/12.5) or a shift clock gated off (11.x).
• What management cares about: that the team doesn't waste days on phantom logic bugs — a 30-second flush protects schedule and points at the real break.

4. Concept — the flush test, signatures, and counting

The flush (chain-integrity) test:

• Shift a known pattern — e.g. 0011 0011… or a walking 1/0 — in at scan-in; observe it at scan-out, delayed by the chain length.
• In = Out (delayed) → chain GOOD. In ≠ Out → chain BROKEN. This is the first test on any device and the first debug step for any scan failure.

Failure signatures (read the output):

• STUCK chain (stuck-at-0/1 somewhere): output is a constant (all 0 / all 1) regardless of input → the stuck bit position localizes the bad cell. The shift-mode timing this interacts with is covered in shift and capture timing.
• OPEN/BROKEN chain: pattern doesn't propagate past a point → downstream reads constant/garbage, upstream is fine → the transition point localizes the break.
• SLOW/TIMING chain: flushes at slow shift, fails at fast shift → a HOLD violation between adjacent cells (12.2 shift=hold) or a missing lock-up latch (4.x) → data races through / double-clocks; intermittent / at-speed, passes slow.
• SHORTED/INVERTED/CLOCK: a bridge, an odd inversion in the path, or a cell not clocked (its shift clock gated off, 11.x, or an async reset firing in shift) → each has a distinct flush signature; a not-clocked cell holds its value.

Localization = counting:

• A chain is an ordered shift register (how it is stitched), so the cell position where the flush breaks maps to a physical cell/net. Once localized, diagnosis and failure localization takes it to the defect.
• Count from the scan-out end, not the scan-in end. The bits that emerge first at scan-out come from the cells nearest scan-out — the ones downstream of the break, flushing their prior contents. The pattern you shifted in never arrives at all.
• With a chain of N cells numbered 1..N from scan-in, and C bits of prior data observed before the output goes constant: k = N + 1 − C. Getting the direction wrong sends you to the opposite end of the chain. Chain-diagnosis tools automate this.

Clocks/resets as chain killers:

• A cell whose shift clock is gated off in shift (11.x ICG/test-clock), or an async reset firing in shift, corrupts the chain and looks like a break.
• Verify clocks/resets in SHIFT mode (12.5 shift run) before blaming the cell.

The rule:

• A good flush is the license to debug patterns. If the flush fails, everything else is noise → fix the chain first. Multiple chains → flush each; the failing chain is isolated.

5. Mental Model — testing a garden hose before blaming the sprinkler

Debugging a scan chain is like testing a garden hose before you blame the sprinkler for not spraying.

• The hose is the chain; the water you push in is the flush pattern; the water out the end is the scan-out. If you push water in one end and the same water comes out the other (delayed by the hose length), the hose is good — now you can debug the sprinkler (the patterns/logic).
• If nothing comes out, or a constant trickle no matter what you push, the hose is blocked or cut — debugging the sprinkler is pointless. A constant output is a kink that's fully shut (stuck); water coming out fine up to a point then nothing is a cut at that point (open) — and you localize by walking the hose to where the flow stops (counting to the last-good cell).
• A hose that works at low pressure but bursts at high pressure is a timing chain (fine slow, fails fast — a hold issue). And a valve someone left shut (a gated shift clock) blocks flow just like a cut — check the valves (clocks/resets in shift) before you replace the hose.

Test the hose (flush the chain) before blaming the sprinkler (patterns) — a constant/no output means a blockage or cut; walk the hose to localize; check the shut valves (clocks) too.

6. Working Example — flush, classify, localize by counting

Trace a flush and localize the break:

# Scan-chain flush + localization - REPRESENTATIVE, tool-neutral:
  FLUSH: shift a known pattern IN, observe OUT (delayed by chain length N)
    scan_in  : 0 0 1 1 0 0 1 1 ...
    scan_out : ......  0 0 1 1 0 0 1 1   (delayed by N)  -> In = Out  -> CHAIN GOOD -> license to debug patterns
  --- if BROKEN, classify by signature ---
    scan_out = 0 0 0 0 0 0 ...  (constant, any input)         -> STUCK chain (stuck-at-0) ; stuck-bit position -> bad cell
    scan_out shows C bits of PRIOR data then goes constant     -> OPEN chain ; break at cell k = N + 1 - C (count from SCAN-OUT)
    flush OK at SLOW shift, corrupts at FAST shift             -> TIMING chain ; hold violation / missing lock-up (12.2/4.x)
    one bit inverted vs expected everywhere                    -> INVERTED path segment
  --- LOCALIZE by COUNTING (ordered shift register) ---
    the leading bits at scan-out are the cells DOWNSTREAM of the break flushing their prior contents
    so C observed bits => N + 1 - C cells lie between scan-in and the break => break is at cell k = N + 1 - C
    sanity: C = 1 means the break is at the LAST cell (nearest scan-out) ; C = N means it is at the FIRST
  --- CLOCK/RESET check (chain killers) ---
    a cell whose SHIFT clock is gated OFF (11.x) holds its value -> looks like a break ; an async reset firing in shift corrupts
    -> verify clocks/resets in the SHIFT run (12.5) BEFORE blaming the cell
  RULE: a good FLUSH is the LICENSE to debug patterns ; if flush fails, EVERYTHING else is noise -> fix the chain first.

A break at cell k isolates everything downstream of it from scan-in. Those downstream cells still shift, so they flush their prior contents out first — which is why the count runs from the scan-out end:

6b. The localization worked through

The arithmetic is worth doing once on real numbers, because the direction is the part people get wrong and the consequence is looking at the opposite end of a thousand-cell chain.

CHAIN UNDER TEST
  length N            = 1000 cells, numbered 1..1000 from scan-in
  flush pattern in    = 0011 0011 ... (continuous)
  expected at scan-out= the same pattern, delayed by 1000 shifts
 
TESTER LOG (abridged)
  shift  1 .. 380 : scan_out toggles, but does NOT match the delayed pattern
  shift 381 ..    : scan_out constant 0 for the rest of the burst
  verdict         : CHAIN FAIL - open/stuck, not a pattern problem
 
READ IT
  C = 380 bits of data emerged before the output went constant.
  Those bits are NOT the pattern we shifted in - that pattern never arrived.
  They are the PRIOR CONTENTS of the cells sitting between the break and
  scan-out, flushing themselves out.
 
  So 380 cells lie downstream of the break, and
 
      k = N + 1 - C = 1000 + 1 - 380 = 621
 
  The break is at cell 621, counting from scan-in.
 
SANITY-CHECK THE DIRECTION (do this every time)
  C = 1    -> k = 1000 : break at the LAST cell, nearest scan-out
  C = N    -> k = 1     : break at the FIRST cell, nearest scan-in
  Both match intuition. If your formula gives the opposite, you have counted
  from the wrong end - and on this chain that is a 380-cell error.
 
NEXT STEP
  Map cell 621 in the stitched chain order to its instance name (see
  /dft/scan-stitching-ordering for how that order is decided), then inspect
  that cell and the net driving its SI. Check the SHIFT-mode clock and reset at
  that cell BEFORE assuming a physical open: a gated shift clock or an async
  reset firing during shift produces this exact signature.

6c. A flush checker you can run in simulation

Before silicon, the same classification can run against the netlist. This checker drives a flush, classifies the signature, and computes the break position with the arithmetic above.

module scan_flush_check #(
  parameter int CHAIN_LEN = 1000
) (
  input logic tck,
  input logic scan_enable,
  input logic scan_in,
  input logic scan_out
);
  // Drive a known pattern and record what comes back.
  logic [CHAIN_LEN*2-1:0] observed;
  int unsigned n;
 
  task automatic run_flush(output string verdict, output int break_cell);
    logic prev; int const_run; int first_const;
    n = 0; const_run = 0; first_const = -1;
 
    // Shift a continuous 0011 pattern for twice the chain length so that a
    // healthy chain has time to present the delayed pattern at scan_out.
    repeat (CHAIN_LEN*2) begin
      @(negedge tck);
      // pattern generator: 0,0,1,1,0,0,1,1,...
      force scan_in = ((n >> 1) & 1);
      @(posedge tck);
      observed[n] = scan_out;
 
      // Track how long the output has been constant.
      if (n > 0 && scan_out === prev) begin
        const_run++;
        if (const_run == 8 && first_const < 0) first_const = n - 8;
      end else begin
        const_run = 0;
      end
      prev = scan_out;
      n++;
    end
    release scan_in;
 
    // ---- Classify -------------------------------------------------------
    if (first_const == 0) begin
      // Constant from the very first observed bit: nothing downstream of the
      // break had anything to flush, or the whole chain is stuck.
      verdict = "STUCK chain (constant from bit 0)";
      break_cell = CHAIN_LEN;                       // nearest scan-out
    end else if (first_const > 0) begin
      // C bits of prior data emerged, then constant.
      verdict = "OPEN chain";
      break_cell = CHAIN_LEN + 1 - first_const;     // count from SCAN-OUT
    end else begin
      verdict = "chain integrity OK";
      break_cell = -1;
    end
  endtask
 
  string  v;
  int     kbreak;
 
  initial begin
    wait (scan_enable === 1'b1);
    run_flush(v, kbreak);
    if (kbreak < 0)
      $display("FLUSH PASS: %s", v);
    else
      $error("FLUSH FAIL: %s - break at cell %0d of %0d (counted from scan-out)",
             v, kbreak, CHAIN_LEN);
  end
endmodule

Run this at the slow shift frequency first. A chain that fails here has a structural problem — a break, a stuck node, a gated clock — and no amount of pattern debug will help. A chain that passes here and fails at speed is a different problem entirely, and it is the subject of the Debug Lab below.

7. Industry Flow — flush first, then branch

The flow branches on the flush: a good flush licenses pattern debug; a bad flush is classified, localized, and fixed:

8. Debugging Session — every pattern fails on one chain

9. Common Mistakes

• Debugging patterns before flushing. A dead chain fails every pattern — flush first (structure before function, 13.1).
• Ignoring the signature. Constant = stuck; downstream-dead = open; fast-fail/slow-pass = timing (12.2) — each localizes differently.
• Not counting to localize. The cell position of the break maps to a physical cell — count the good bits.
• Blaming the cell before checking clocks/resets. A gated shift clock or async reset in shift looks like a break (12.5).
• Not flushing each chain. With multiple chains, flush each to isolate the failing one.

10. Industry Best Practices

• Flush every chain first — a known pattern in/out — as step zero of any scan debug.
• Read the signature (stuck/open/timing/clock) to classify the failure before localizing.
• Localize by counting the good bits to the last-good cell; use chain-diagnosis tools.
• Verify shift-mode clocks/resets (12.5) before blaming a cell — they're common chain killers.
• Only debug patterns on a good flush — the flush is the license.

11. Senior Engineer Thinking

• Beginner: "Every pattern fails on this chain — must be a big logic bug; let me debug the patterns."
• Senior: "Every pattern failing on one chain smells like a dead chain, not logic. Flush first: a constant output = stuck. I count the good bits to the stuck cell, and I check shift-mode clocks/resets before blaming the cell — often it's a gated shift clock (11.x). Fix the chain, re-flush, then debug patterns. A good flush is the license to debug patterns."

The senior flushes first, reads the signature, and localizes by counting — never debugging patterns on an unverified chain.

12. Silicon Impact

Scan-chain debug is the highest-leverage step in the entire debug chapter, because the chain is the delivery mechanism for every pattern — so its health gates the meaning of everything downstream. The governing insight, inherited from structure before function (13.1), is blunt: a broken chain makes every pattern miscompare, so debugging patterns or logic on a dead chain is chasing a bug that doesn't exist — the classic, avoidable DFT waste (three days on a chain a 30-second flush would have shown dead). The flush (chain-integrity) test is the antidote: shift a known pattern in and observe it out, delayed by the chain length — In=Out is the license to debug patterns, and a mismatch stops you cold. Crucially, a chain fails in readable signatures: a STUCK chain outputs a constant regardless of input (the stuck bit localizes the cell); an OPEN chain kills everything downstream of a break while upstream stays good (the transition point localizes it); a TIMING chain flushes slow but fails fast — the HOLD violation between adjacent cells or a missing lock-up latch (12.2 shift=hold, 4.x); and a cell whose shift clock is gated off (11.x) or whose async reset fires in shift looks like a break — so you verify clocks/resets in the shift run (12.5) before blaming the cell. Because a chain is an ordered shift register, localization is counting: the cell position where the flush breaks maps to a physical cell/net — count the good bits to the last-good cell and the break is at or after it (chain-diagnosis tools automate this). For the test/DFT engineer, the flush is step zero; for the physical engineer, the count points at the exact instance (an open, a short, a clock issue); for the STA engineer, a timing chain is a shift-mode hold problem (12.2/12.5); and for the whole program, the discipline protects schedule by ending phantom-logic-bug chases. The rule that makes it all work is the one to carry into 13.3: a good flush is the license to debug patterns — with multiple chains, flush each to isolate the failing one, then start pattern debug (13.3) from a chain you know is good, so the failures you see there are real logic/pattern issues, not a dead chain masquerading as a thousand bugs.

13. Engineering Checklist

• Flushed every chain first — known pattern in/out; In=Out (delayed) = good.
• Classified the signature — stuck (constant) / open (downstream-dead) / timing (fast-fail) / clock (looks-broken).
• Localized by counting the good bits to the last-good cell; mapped to a physical cell/net.
• Verified shift-mode clocks/resets (12.5) before blaming a cell.
• Only debugged patterns on a good flush — the flush is the license (13.3).

14. Try Yourself

1. Describe the flush test and what In=Out (delayed) vs a mismatch tells you.
2. Give the flush signatures for stuck, open, timing, and clock-off chains — and how each localizes.
3. Localize a break by counting: given the flush good for the first k bits then constant, where's the break?
4. Explain why a gated shift clock or an async reset in shift looks like a break (12.5) — and how to check.
5. State the rule: a good flush is the license to debug patterns — and why you flush each chain.

The flush/localization reasoning is tool-neutral; the flush runs on the ATE, chain diagnosis is a DFT tool. No paid tool required to reason about chain debug.

15. Interview Perspective

• Weak: "If scan fails, I look at which patterns fail."
• Good: "I flush the chain first — shift a known pattern in and out; if it doesn't match, the chain is broken before I debug patterns."
• Senior: "The chain delivers every pattern, so a broken chain fails all of them — structure before function: I flush first. A known pattern in, observe out delayed — In=Out licenses pattern debug, a mismatch stops me. I read the signature: constant out = stuck, downstream-dead = open, fails-fast/passes-slow = a timing (hold) chain (12.2), and a gated shift clock or async reset in shift looks like a break. Then I localize by counting the good bits to the last-good cell — the chain is an ordered shift register, so the position maps to a physical cell. I verify shift-mode clocks/resets (12.5) before blaming the cell. A good flush is the license to debug patterns — and I flush each chain to isolate the failing one."

16. Interview / Review Questions

16b. Where This Is Specified

• IEEE 1149.1-2013 — Standard for Test Access Port and Boundary-Scan Architecture. The boundary-scan register and the TAP that shifts it, whose chain-integrity behaviour follows the same ordered shift-register model as an internal scan chain.
• IEEE 1500-2005. Core test wrappers and their wrapper chains, which are localized with the same counting method.
• Synopsys Design Constraints (SDC). set_case_analysis for selecting shift mode and create_clock for the shift clock — the constraints whose absence leaves cell-to-cell shift paths out of the timing graph entirely.

Scan stitching order, lock-up latch insertion, chain-diagnosis pattern formats and ATE log conventions are established engineering practice rather than standardised behaviour, and are documented per tool and per tester.

17. Key Takeaways

• A broken chain makes every pattern miscompare — so flush first (structure before function, 13.1): shift a known pattern in, observe it out (delayed) — In=Out = GOOD (license to debug patterns), mismatch = BROKEN (fix the chain first).
• Read the signature: STUCK = constant output; OPEN = downstream dead / upstream good; TIMING = fails fast, passes slow (a hold violation / missing lock-up, 12.2/4.x); CLOCK/RESET off = looks like a break.
• Localize by counting — the chain is an ordered shift register, so the cell position of the break maps to a physical cell/net (count the good bits to the last-good cell).
• Verify shift-mode clocks/resets (12.5) before blaming a cell — a gated shift clock (11.x) or async reset in shift is a common chain killer that mimics a break.
• A good flush is the license to debug patterns — with multiple chains, flush each to isolate the failing one, then move to pattern debug. Next: 13.3 — debugging pattern mismatches.

18. Quick Revision

Debugging scan-chain failures. A broken chain fails EVERY pattern → FLUSH FIRST (structure before function, 13.1): shift a KNOWN pattern IN, observe OUT (delayed by chain length). In=Out → GOOD (license to debug patterns) ; mismatch → BROKEN. Signatures: STUCK = constant out (any input) ; OPEN = upstream good, downstream dead ; TIMING = flushes SLOW, fails FAST (hold / missing lock-up, 12.2/4.x) ; CLOCK-off cell holds value / async reset in shift = looks broken. Localize by COUNTING good bits → last-good cell → map to physical cell/net (ordered shift register). Check shift-mode clocks/resets (12.5) BEFORE blaming the cell. Multiple chains → flush EACH, isolate the failing one. A good flush = the license to debug patterns. Next: 13.3 — pattern mismatches.