Skip to content
VLSIMentor

DFT · Chapter 11 · Test Modes & DFT Signals

Scan-Enable, Test-Clock & Reset Control

Three test control signals matter more than any others, and getting their distribution and timing right is what makes structural test work in real silicon. Scan-enable toggles the design between shift and capture every cycle, so as a global high-fanout signal it must settle at every flop before the capture edge, which becomes a race at-speed and needs balanced distribution or a dedicated fast scan-enable. The test clock comes from a controlled source: a slow shift clock from the tester plus an at-speed capture clock from on-chip clock control, selected glitch-free across multiple clock domains. Reset control gates asynchronous set and reset off during test so they cannot corrupt loaded state, while a controlled test reset stays available to set a known state. Get these three right and at-speed scan, capture, and BIST all work.

Intermediate13 min readDFTScan EnableTest ClockReset ControlAt-Speed

Chapter 11 · Section 11.3 · Test Modes & DFT Signals

Project thread — the mini-SoC's big-three controls (SE distribution, OCC clocking, reset gating) make its at-speed scan and BIST work; 11.5 shows them on a clock-gated block.

1. Why Should I Learn This?

The big three — scan-enable, test-clock, reset — are the most timing-critical test controls; their distribution/timing decides whether at-speed test works.

  • Scan-enable: dynamic, global — must settle at every flop before capture (a race at-speed, 3.4).
  • Test-clock: shift clock (slow) + at-speed via OCC; glitch-free selection; multi-domain care.
  • Reset: gated off in test (4.4) so it can't corrupt state — kept controllable for a known init.
  • Their distribution + timing is essential — a late SE / glitching clock / active reset corrupts the test.

2. Real Silicon Story — the at-speed test that failed on the big three

A chip's slow (stuck-at) scan passed, but at-speed (transition) test failed intermittently. Three separate near-misses in the big-three controls conspired: the scan-enable hadn't fully settled at the far flops before the fast capture edge (3.4); a clock selection occasionally glitched at the shift↔capture switch (11.2); and on one block an async reset wasn't fully gated, so it could nudge state during the test (4.4).

None was a logic bug — all three were control distribution/timing issues, and at-speed exposed them because its timing margins are tight. Slow test tolerated them (SE had time to settle, glitches settled, reset windows were wide); at-speed did not.

The fixes were big-three discipline: balance/pipeline SE (and add a dedicated fast SE) so it settles before capture; use a glitch-free clock mux / OCC for clean at-speed launch/capture; and fully gate the reset in test (keeping it controllable for init). At-speed then passed. Lesson: at-speed test lives or dies on the big three — SE settle, glitch-free clocking, reset gating — and their distribution/timing is the difference between at-speed that works and at-speed that corrupts intermittently.

3. Factory Perspective — the big three through each lens

  • What the DFT engineer sees: the SE distribution (fanout/skew), the clock sources (shift + OCC), and the reset gating — the timing-critical controls to get right for at-speed.
  • What the CTS/physical engineer sees: SE as a balanced, timing-critical net, the glitch-free clock mux / OCC, and the reset distribution — all physical timing tasks.
  • What the RTL/DV engineer sees: the reset discipline (gate off in test, keep a known init) and that SE settle / clock selection are constraints their design must respect.
  • What management cares about: that at-speed test (needed for timing defects/DPPM, 2.3/1.5) depends on the big three — a schedule risk if their distribution/timing is left late.

4. Concept — the three signals and their distribution/timing

Scan-enable (SE) — dynamic, global, must settle before capture:

  • Role: selects shift (SE=1) vs capture (SE=0) — toggled every cycle (3.4). It's dynamic (the exception vs static mode signals, 11.2).
  • Distribution: global, high-fanout → treat as a timing-critical net: balance/pipeline it, control skew.
  • The timing requirement: SE must settle to its capture value at every flop before the capture edge. Trivial slow, a race at-speed (fast capture beats a slow SE) → sometimes a dedicated fast scan-enable for at-speed (3.4).

Test-clock — shift clock + at-speed via OCC:

  • Shift clock: slow, tester-driven, used to shift the chains (3.4).
  • Capture clock: the functional / at-speed clock, generated by on-chip clock control (OCC) (2.3/4.4) for the launch+capture pair.
  • Selection must be glitch-free (11.2 — a clock glitch is a spurious edge). Multiple clock domains need careful control (which clock pulses when, inter-domain).

Reset — gated off in test, kept controllable:

  • Async set/reset gated off during test (4.4) so it can't fire and corrupt the loaded state.
  • But kept controllable — a controlled test reset to initialize a known state (then hold inactive). Reset's own faults are still tested via a controlled path.

The shared theme — distribution + timing is essential:

  • SE: settle-before-capture (distribution/skew).
  • Clock: glitch-free selection + OCC at-speed timing.
  • Reset: gated (inactive) yet controllable.
  • At-speed exposes any weakness (tight margins); slow test tolerates it.
Scan-enable distributed globally and settling before capture, test-clock selecting shift or at-speed via OCC glitch-free, and reset gated off but controllable in testSCAN-ENABLE (dynamic,global)toggles shift↔capture percycle (3.4)→ must settle beforecapturebalance/pipeline; dedicatedfast SE at-speedTEST-CLOCKshift (slow) + at-speed(OCC)→ glitch-freeselectionclock glitch = spuriousedge (11.2); multi-domainRESETgated OFF in test (4.4)→ but controllableknown init, then holdinactive12
Figure 1 - the big-three test controls (representative). SCAN-ENABLE: a global, high-fanout, DYNAMIC signal (toggles shift<->capture per cycle) -> must be balanced/pipelined so it SETTLES at every flop BEFORE the capture edge (a race at-speed; sometimes a dedicated FAST SE). TEST-CLOCK: selects the SHIFT clock (slow, tester) or the AT-SPEED capture clock (via OCC) -- selection must be GLITCH-FREE (a clock glitch = a spurious edge), multi-domain aware. RESET: async set/reset GATED OFF in test (so it can't corrupt loaded state) but kept CONTROLLABLE for a known init. Their distribution + timing is what makes at-speed test valid.

5. Mental Model — a pit crew's three critical calls

The big three are like a pit crew's three most timing-critical calls during a fast stop.

  • Scan-enable is the 'go/hold' signal to every crew member — it must reach all of them in sync before the car launches (the capture edge). At a slow stop there's slack; at a fast stop, if the call is late to the far crew member, the car launches while they're still working — disaster (the at-speed SE-settle race). So you wire the call carefully (balance) and maybe give the far members a faster line (dedicated fast SE).
  • Test-clock is the crew's cadence — you must switch cleanly between the slow prep rhythm (shift clock) and the fast go rhythm (at-speed/OCC) without a stumble (a glitch = a false beat that throws everyone off).
  • Reset is the 'clear the box' command — you disable it during the stop (gated off) so it can't wipe the setup mid-work, but you keep it available to set a known starting arrangement before you begin.
  • Get all three synchronized and clean and the fast stop works; get any one late, stumbling, or firing at the wrong time, and the stop falls apart — and it's the fast stops (at-speed) where it shows.

Three critical calls — reach everyone in time (SE), keep a clean cadence (clock), and disable 'clear' during work (reset) — is what makes the fast stop work.

6. Working Example — the big three across a scan test

Trace the big three through a shift → capture at-speed test:

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
# The big three across an at-speed scan test - REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  SHIFT phase:
    scan_enable = 1 (DYNAMIC, global) ; clock = SHIFT clock (slow, tester) ; reset = GATED OFF (held inactive, 4.4)
    -> load the scan chains
  MODE SWITCH (the critical window):
    scan_enable must SETTLE to 0 at EVERY flop BEFORE the capture edge (balance/pipeline SE; dedicated FAST SE)
    clock selection SHIFT -> AT-SPEED must be GLITCH-FREE (OCC, 11.2)
  CAPTURE phase:
    scan_enable = 0 (settled everywhere) ; clock = AT-SPEED launch+capture (OCC, 2.3) ; reset still GATED OFF
    -> the logic responds at speed, captured
  SHIFT-OUT: scan_enable = 1 ; SHIFT clock ; unload + compare
# If SE is late at some flops at the fast capture edge -> those flops stay in shift mode -> corrupted capture (3.4).
# If the clock selection GLITCHES -> spurious edge -> corrupted state (11.2). If reset FIRES -> state cleared (4.4).

7. Industry Flow — the big three make at-speed work

The big three are the timing-critical controls that make at-speed capture valid:

Shift with scan-enable high and slow clock, a critical mode switch where scan-enable settles and the clock switches glitch-free, capture at-speed with scan-enable low, then shift outThe big three across shift → (settle) → at-speed capture → shift-outThe big three across shift → (settle) → at-speed capture → shift-out1Shift (SE=1, slow clock)reset gated off → load chains2Mode switch (critical)SE settles; clock switches glitch-free (OCC)3Capture (SE=0, at-speed OCC)logic responds at speed4Shift-out (SE=1)unload + compare5Valid at-speed testbig-three timing makes it work
Figure 2 - the big three across the scan-test phases (representative). SHIFT: scan_enable=1 (slow shift clock), reset gated off -> load chains. MODE SWITCH (critical): SE must SETTLE to 0 at every flop, and the clock selection (shift -> at-speed) must be GLITCH-FREE (OCC). CAPTURE: scan_enable=0 everywhere, at-speed launch+capture via OCC, reset still gated -> valid at-speed response. SHIFT-OUT: scan_enable=1, unload. The big-three distribution/timing (SE settle, glitch-free clock, gated reset) is exactly what makes at-speed test valid; a weakness in any shows up at-speed (tight margins), not slow.

8. Debugging Session — at-speed corrupts, slow passes

1

Slow scan passes but at-speed test corrupts intermittently, and the team suspects a design bug; the big-three test controls have near-misses that slow test tolerates but at-speed exposes -- scan-enable not settled at all flops before the fast capture edge, a glitching clock selection, or an ungated reset -- so the fix is big-three timing discipline: balance/pipeline SE (dedicated fast SE), glitch-free clock/OCC, and fully gate the reset

AT-SPEED LIVES OR DIES ON THE BIG THREE: SE SETTLE, GLITCH-FREE CLOCK, GATED RESET
Symptom

Slow (stuck-at) scan passes, but at-speed (transition) test corrupts intermittently — different dies, different runs, no consistent fault. The team suspects a logic bug or a marginal design.

Root Cause

The big-three test controls (scan-enable, test-clock, reset) have distribution/timing near-misses that slow test tolerates but at-speed exposes, because at-speed's tight margins leave no slack. At-speed test uses a fast capture with tight timing, so any weakness in the controls that govern when and how flops capture shows up. Three usual culprits, all control (not logic) issues: (1) Scan-enable not settled — SE is global and high-fanout, and at the fast capture edge it may not have reached its capture value (0) at the far/heavily-loaded flops (the 3.4 SE-settle race); those flops are still in shift mode and capture the wrong thing. (2) Glitching clock selection — switching shift↔at-speed clock with a non-glitch-free mux produces a spurious edge (11.2) that clocks flops unexpectedly. (3) Ungated/marginal reset — an async reset not fully gated off in test can nudge/clear state during the tight capture window (4.4). Slow test tolerates all three (SE has time to settle, glitches settle within wide windows, reset windows are wide); at-speed does not, so the same 'good' design corrupts only at-speed — and because it depends on exact timing alignment, it's intermittent. It's not a logic bug; it's big-three control distribution/timing.

Fix

Apply big-three timing discipline: balance/pipeline scan-enable (add a dedicated fast SE) so it settles before capture, switch clocks glitch-free with OCC for clean at-speed launch/capture, and fully gate the reset in test. For SE: treat it as a timing-critical, balanced net — pipeline it and/or provide a dedicated fast scan-enable for at-speed so it settles to 0 at every flop before the capture edge (3.4), and verify the SE-to-capture timing. For the clock: use a glitch-free clock mux / OCC (2.3/11.2) so the shift→at-speed switch produces no spurious edge and OCC delivers a clean launch+capture pair. For reset: ensure the async reset is fully gated off in test (4.4) so it can't fire during capture, while keeping a controlled path for known init. Re-run at-speed; the intermittent corruption should clear. The principle to lock in: the three most critical test control signals are scan-enable, test-clock, and reset, and getting their distribution and timing right is what makes at-speed structural test valid — scan-enable is a dynamic, global signal that must settle at every flop before the capture edge (balance/pipeline it, use a dedicated fast SE at-speed), the test-clock must switch shift↔at-speed glitch-free (OCC) since a clock glitch is a spurious edge, and the reset must be gated inactive in test yet controllable; a design that passes slow scan but corrupts at-speed intermittently almost always has a big-three distribution/timing weakness, not a logic bug, because at-speed's tight margins expose what slow test tolerates. (SE settle is 3.4; glitch-free clocking is 11.2; OCC/at-speed is 2.3; reset gating is 4.4; STA constraints are Chapter 12.)

9. Common Mistakes

  • Treating scan-enable as ordinary. It's global/dynamic and must settle before capture — balance/pipeline, dedicated fast SE.
  • Naive clock selection. Shift↔at-speed must be glitch-free (OCC) — a clock glitch is a spurious edge (11.2).
  • Leaving reset ungated in test. Async reset must be gated off (4.4) yet controllable for init.
  • Assuming slow-pass = at-speed-pass. At-speed's tight margins expose big-three weaknesses slow test tolerates.
  • Deferring big-three timing to late. SE/clock/reset distribution is a CTS/physical task to plan early.

10. Industry Best Practices

  • Distribute scan-enable as a balanced/pipelined, timing-critical net; dedicated fast SE for at-speed.
  • Switch clocks glitch-free via OCC; deliver clean at-speed launch/capture; handle multi-domain carefully.
  • Gate reset off in test (4.4) but keep a controllable test reset for known init.
  • Verify big-three timing (SE settle, glitch-free clock, reset windows) — especially at-speed.
  • Plan big-three distribution early — it's a CTS/physical and STA (Ch12) concern.

11. Senior Engineer Thinking

  • Beginner: "Slow scan passes but at-speed corrupts — the design's marginal."
  • Senior: "At-speed's tight margins expose the big three. Is scan-enable settled at every flop before the fast capture (balance/pipeline it, dedicated fast SE)? Is the clock switch glitch-free (OCC)? Is the reset fully gated (4.4)? Slow test tolerated near-misses at-speed can't. It's control distribution/timing, not a logic bug."

The senior debugs at-speed corruption as a big-three (SE/clock/reset) distribution/timing issue, not a logic bug.

12. Silicon Impact

Scan-enable, test-clock, and reset are the big three because they govern the three things that make a structural test valid — when flops shift vs capture (SE), what clocks them (test-clock), and their reset (gating) — and their distribution and timing are what make at-speed test work. At-speed matters enormously (it catches timing defects, 2.3, and underwrites DPPM, 1.5), and its tight margins are exactly what expose any weakness in the big three: a slow test tolerates a late scan-enable, a glitching clock switch, or a marginally-gated reset, but at-speed does not — so a design that passes slow scan yet corrupts at-speed intermittently almost always has a big-three control problem, not a logic bug (the story), a diagnosis that saves teams from chasing phantom design faults. Each signal has a specific discipline: scan-enable is a dynamic, global, high-fanout net that must settle at every flop before the capture edge (balance/pipeline it, add a dedicated fast SE at-speed, 3.4); the test-clock must switch shift↔at-speed glitch-free via OCC because a clock glitch is a spurious edge (11.2/2.3); and the reset must be gated inactive in test yet controllable for a known init (4.4). Crucially, these are distribution/timing concerns — CTS/physical tasks to plan early and constrain in STA (Chapter 12) — not RTL logic. For the DFT/CTS engineer, the big-three timing/distribution spec is the timing-critical heart of DFT control; for the RTL/DV engineer, reset discipline and respecting SE/clock constraints are the obligations. Get the big three right and at-speed scan and BIST produce valid results; get any wrong and the test corrupts intermittently in the field of the most valuable (timing) coverage. These three are the signals the isolation (11.4) and clock-gated example (11.5) build on, and the ones Chapter 12 must constrain and time.

13. Engineering Checklist

  • Scan-enable distributed as a balanced/pipelined timing-critical net; dedicated fast SE for at-speed; settles before capture (3.4).
  • Test-clock switched glitch-free (OCC); clean at-speed launch/capture; multi-domain handled.
  • Reset gated off in test (4.4) yet controllable for known init.
  • Verified big-three timing at at-speed (SE settle, glitch-free clock, reset windows).
  • Planned big-three distribution early (CTS/physical) and constrained in STA (Ch12).

14. Try Yourself

  1. Trace scan-enable across shift → capture; mark the settle-before-capture window and why it's a race at-speed.
  2. Show the test-clock switching shift → at-speed (OCC) and why it must be glitch-free.
  3. Show the reset gated off during the test and kept controllable for init (4.4).
  4. Explain why slow scan passes but at-speed corrupts when the big three are marginal (tight margins).
  5. Give the fixes: balance/pipeline SE (+ fast SE), glitch-free clock/OCC, fully gated reset.

The big-three timing is tool-neutral; distribution is CTS/physical. No paid tool required to reason about them.

15. Interview Perspective

  • Weak: "Scan-enable switches shift and capture; the test clock clocks the design."
  • Good: "Scan-enable must settle before capture, the clock switches glitch-free via OCC, and reset is gated off in test."
  • Senior: "The big three are scan-enable, test-clock, and reset, and their distribution/timing makes at-speed test valid. Scan-enable is dynamic and global — it must settle at every flop before the capture edge, easy slow but a race at-speed, so I balance/pipeline it and add a dedicated fast SE. Test-clock is a slow shift clock plus the at-speed capture clock via OCC, and the switch must be glitch-free — a clock glitch is a spurious edge that corrupts state. Reset is gated off in test (4.4) so it can't corrupt the loaded state, but kept controllable for a known init. The tell: if slow scan passes but at-speed corrupts intermittently, it's a big-three distribution/timing issue — SE not settled, a glitching clock, or an ungated reset — not a logic bug, because at-speed's tight margins expose what slow tolerates."

16. Interview / Review Questions

17. Key Takeaways

  • The big three test controls are scan-enable, test-clock, and reset, and their distribution and timing are what make at-speed structural test valid.
  • Scan-enable is dynamic and global (toggles shift↔capture per cycle, 3.4) and must settle at every flop before the capture edge — trivial slow, a race at-speed → balance/pipeline it, add a dedicated fast SE.
  • Test-clock provides a slow shift clock (tester) plus the at-speed capture clock via OCC (2.3/4.4); its shift↔at-speed selection must be glitch-free (a clock glitch is a spurious edge, 11.2), with multi-domain care.
  • Reset is gated off during test (4.4) so it can't corrupt the loaded state, yet kept controllable for a known init.
  • At-speed's tight margins expose big-three weaknesses that slow test tolerates — so slow passes but at-speed corrupts intermittently is almost always a big-three distribution/timing issue (late SE, glitching clock, ungated reset), not a logic bug — fixed with big-three discipline and constrained in STA (Chapter 12). Next: 11.4 — isolating functional logic in test.

18. Quick Revision

The big three: scan-enable, test-clock, reset. Their distribution + timing make at-speed test valid. SCAN-ENABLE: dynamic, GLOBAL, high-fanout → must SETTLE at every flop BEFORE the capture edge (easy slow, a RACE at-speed → balance/pipeline, dedicated FAST SE, 3.4). TEST-CLOCK: slow shift clock (tester) + at-speed capture via OCC (2.3); selection must be GLITCH-FREE (clock glitch = spurious edge, 11.2); multi-domain aware. RESET: async set/reset GATED OFF in test (can't corrupt loaded state, 4.4) but kept CONTROLLABLE for known init. Slow passes but at-speed corrupts intermittently = a big-three distribution/timing issue (late SE / glitching clock / ungated reset), NOT a logic bug (at-speed's tight margins expose what slow tolerates). Constrained in STA (Ch12). Next: 11.4 — isolating functional logic in test.