In short: Scan-based silicon debug reuses the DFT scan chains already in your chip to freeze the clock, shift out every flop's value as a snapshot of internal state, and compare it against RTL/gate-level simulation to pin a post-silicon bug down to the exact failing flop and cycle.
When first silicon comes back from the fab and a test fails, you cannot probe a 5 nm die with an oscilloscope. The internal nodes are buried under ten metal layers and switch in picoseconds. Scan-based silicon debug solves this by borrowing the same scan infrastructure inserted for manufacturing test, and turning it into a logic-analyzer for the whole flop population of the design.
Why scan is the natural debug fabric
A typical SoC already stitches 95–99% of its flip-flops into scan chains for stuck-at and transition ATPG. Each flop is a mux-D scan cell: in functional mode it captures its data input; in shift mode it becomes a bit in a long shift register driven by a dedicated scan_enable. Because that observability is already there and verified at tapeout, debug reuses it for free — no extra area, no new probe pads.
A mid-size block with 200,000 flops split across 32 scan chains needs ~6,250 shift cycles to dump a complete state snapshot. At a 50 MHz shift clock that is ~125 µs per snapshot — fast enough to capture thousands of snapshots across a failing scenario.
The capture-and-shift mechanism
The core loop is deceptively simple. You run the device functionally up to the suspect cycle, then stop. The debug controller asserts scan_enable, and instead of advancing the functional state, every flop starts shifting toward the chain output (TDO). You clock the chain the exact number of times needed to empty it, recording each bit. That serialized stream, de-interleaved by chain and by cell order, reconstructs the complete flop state at the stopped cycle.
scan_enable turns the flops into a shift register that serializes all internal state to TDO.Stop-at-cycle: the hard part
Dumping state is easy; stopping at the right cycle is the engineering challenge. Three mechanisms are common:
- Cycle counters in an on-chip debug block that free-run the functional clock for N cycles, then gate it and switch to the shift clock.
- Hardware breakpoint/trigger logic — a small comparator network that watches an address bus, an FSM state, or an assertion signal and halts the clock on match.
- Shift-based "clock chopping", where a programmable clock controller (driven over JTAG/IEEE 1149.1) issues a precise burst of functional pulses.
Because you re-run from reset each time and advance one more cycle, you build a cycle-by-cycle movie of internal state. This re-run determinism is why debuggable chips insist on a clean reset and avoidance of free-running asynchronous sources during the scan-debug window.
From bitstream to root cause
A raw dump of 200k bits is useless without a golden reference. The flow that makes it actionable:
- Run the identical stimulus in gate-level simulation (the same netlist that was taped out), dumping expected flop state at each candidate cycle.
- Map each silicon chain bit back to an RTL/netlist signal name using the scan-cell ordering database your DFT tool emits.
- Diff silicon-vs-sim. The first cycle where a flop diverges, and its fan-in cone, localizes the bug.
The scan-cell order file is the linchpin. Synopsys TetraMAX/DFTMAX, Siemens Tessent, and Cadence Modus all emit a chain description (cell instance, chain index, inversion) — without it, a shifted 1 cannot be traced to a named flop.
| Method | Internal observability | Area cost | Typical use |
|---|---|---|---|
| Scan dump | ~All flops (static snapshot) | ~0 (reuses DFT) | Logic/functional bugs |
| Embedded logic analyzer (ELA) | Few hundred signals, real-time | Moderate (trace RAM) | Timing/protocol traces |
| FIB + e-beam probe | A handful of nodes | Destructive, per-die | Last-resort physical defects |
A worked example
Suppose a DDR controller intermittently drops a write. Functional test flags a bad ECC at transaction 4,117. You configure the debug counter to halt 3 cycles after the controller FSM enters WR_ISSUE, dump all 200k flops, and diff against sim. Fifteen flops differ — all in the write-data FIFO pointer logic. Tracing the first divergence, the read pointer in silicon is one ahead of sim. The fan-in cone reveals a gated-clock enable that glitches when a refresh collides with a write. That is a classic post-silicon timing-margin bug that RTL simulation never exercised, and scan localized it to a single cone in two afternoons rather than weeks of guesswork.
Practical limits and pitfalls
- State loss on shift: shifting is destructive — once you dump, you cannot resume functional operation from that point. Always re-run from reset.
- Non-scan state: embedded SRAM, analog registers, and asynchronously-reset flops may not be in the chain. Memory BIST and dedicated observe points fill the gap.
- Clock-domain crossings: a snapshot straddling an async boundary can show metastable-looking mismatches that are benign — always qualify the stop cycle relative to each domain.
- Compression: on-chip scan compression (DFTMAX/Tessent TestKompress) must be bypassed or decoded, since compressed chains are not directly human-readable.
Teams that treat scan-debug as a tapeout requirement — clean reset, documented chain order, bypassable compression — shorten bring-up dramatically. For the broader flow of powering up first silicon and sequencing these tests, see our companion guide on silicon bring-up, and for building triggers into the die, our note on on-chip debug fabric design. If your team is hardening a DFT and bring-up methodology end to end, the physical-design and verification specialists at Avecas design services run exactly these flows on production tapeouts.
Want to run a full scan-dump-to-root-cause lab on a real netlist? Our Post-Silicon Validation & Debug course on CourseTron walks you through Tessent chain ordering, stop-at-cycle controllers, and sim-vs-silicon diffing hands-on.
Watching state march out
FAQ
How is scan debug different from an embedded logic analyzer?
Scan gives a static snapshot of nearly every flop at one frozen cycle, reusing DFT at zero area cost. An ELA (e.g. Siemens' or an FPGA ILA) captures a few hundred signals in real time into trace RAM. Scan is best for "which flop is wrong"; an ELA is best for "what sequence of events led here".
Can I resume execution after dumping the scan chain?
No. Shifting the chain overwrites functional state, so you cannot continue from the stop point. The standard approach is deterministic re-run from reset, advancing one more cycle per iteration to build a snapshot movie.
What if the bug is in memory, not a flop?
SRAM arrays usually are not in the scan chain. Use memory BIST, direct-access test ports, or dedicated observe flops at memory interfaces, and correlate those with the scan snapshot of surrounding control logic.
Which tools produce the scan-cell order I need for mapping?
Synopsys TetraMAX/DFTMAX, Siemens Tessent, and Cadence Modus all emit a chain-order description listing each scan cell, its chain, position, and inversion — the key that turns an anonymous bitstream into named signals.