Simulating Shift & Capture

Chapter 11 · Section 11.3 · Scan / DFT Interaction

Project thread — the mini-SoC's scan chains (11.2) are exercised by shift/capture cycles. This lesson simulates them; 11.4 runs the ATPG patterns that drive the cycles.

1. Why Should I Learn This?

A scan test is a shift/capture dance — and getting the mode control right is where it works or fails.

• Shift (SE = 1): load/read the chain, bit per clock.
• Capture (SE = 0): one functional clock captures the response.
• SE must be stable at capture; capture uses functional (at-speed) timing.

This connects the chain (11.2) to the ATPG patterns (11.4) and the scan reset/X capstone (11.5).

2. Real Silicon Story — the capture that ran in the wrong mode

A scan test produced mismatches on specific patterns, and the patterns were blamed. Regenerating them didn't help.

The problem was SE timing: the scan-enable glitched (or transitioned too close) at the capture clock edge, so some flops were still in shift mode when the capture happened — they captured scan data instead of the functional response. The capture ran in the wrong mode for those flops → mismatch. Making SE stable and clean across the capture edge fixed it — the patterns were fine all along.

Lesson: the SE must be stable during capture. A glitchy or mistimed SE puts flops in the wrong mode at the capture edge, causing mismatches that look like bad patterns.

3. Concept — the shift/capture cycle

The two modes:

• Shift (SE = 1): flops take scan-in SI — the chain is a shift register; data moves one bit per clock (scan-in → scan-out).
• Capture (SE = 0): flops take functional D — one functional clock captures the combinational response to the loaded pattern.

The test cycle:

1. Shift in a pattern (SE = 1, N shift clocks to fill the chain).
2. Capture the response (SE = 0, one functional clock) — the flops capture what the logic computes from the loaded state.
3. Shift out the captured response (SE = 1) — usually overlapped with shifting in the next pattern — and compare to expected.

Two critical details:

• SE stability at capture: SE must be stable (low) across the capture edge — a glitch or mistimed transition leaves some flops in shift mode → they capture scan data → mismatch.
• Capture timing vs shift timing: capture uses functional timing (the real combinational path, timed by SDF — often at-speed for delay tests), while shift is typically run slow (the chain is a long, timing-relaxed path).

Scope (accuracy):

• GLS simulates shift/capture behaviour with real timing; fault coverage is ATPG's (11.1). At-speed capture needs SDF (Ch4). GLS stays dynamic; STA signs off timing (0.3).

4. Mental Model — load the dice, roll once, read the result

A scan test is like loading dice, rolling once, and reading the result.

• Shift in = setting each die to a chosen face (loading the pattern into the chain, bit by bit).
• Capture = one roll (one functional clock) — the design reacts to the loaded state, and each die records its new face (the response).
• Shift out = reading the dice off the table one by one (shifting the captured response to scan-out) while setting up the next roll (loading the next pattern).
• SE stability = making sure you're in "read the dice" vs "roll" mode cleanly — flip the switch at the wrong instant (glitchy SE at capture) and some dice get set instead of rolled (captured scan data, not the response) → wrong result.

Set the dice (shift), roll once (capture), read them (shift out) — and don't flip the mode switch mid-roll.

5. Working Example — a shift/capture cycle

The cycle in control signals (representative):

# Scan test cycle (tool-neutral) — SHIFT / CAPTURE / SHIFT-OUT:
#   phase 1: SE=1, pulse scan clock N times -> SHIFT IN the pattern (scan_in -> chain)
#   phase 2: SE=0, ONE functional clock      -> CAPTURE the response (flops take functional D)
#   phase 3: SE=1, pulse scan clock N times  -> SHIFT OUT captured response (compare vs expected)
#                                               (overlap: also SHIFT IN the next pattern)
# SE must be STABLE (low) across the capture edge. Capture at functional timing (SDF, at-speed).

// SE stability at capture — REPRESENTATIVE. A glitch/late SE = wrong mode = mismatch.
// GOOD: SE settled low well before the capture edge, held stable across it
// BAD:  SE still transitioning at the capture edge -> some flops in SHIFT -> capture scan data

Practical context (representative, tool-neutral):

# Shift/capture checklist (tool-neutral):
#   [ ] SHIFT: SE=1, N scan clocks to fill the chain (slow timing OK)
#   [ ] CAPTURE: SE=0, ONE functional clock -> response captured
#   [ ] SE STABLE (low) across the capture edge (no glitch/late transition)
#   [ ] capture uses FUNCTIONAL timing (SDF) -- at-speed for delay tests
#   [ ] SHIFT OUT + compare (overlap with loading the next pattern)

A shift/capture cycle (with SE stable at capture), as a real waveform:

6. Debugging Session — a capture that ran in the wrong mode

7. Common Mistakes

• Glitchy or late SE at capture. Flops capture scan data, not the response → mismatch.
• Blaming patterns for a protocol/SE bug. Regenerating patterns won't fix mode control.
• Capturing before the functional path settles. Capture uses at-speed timing (SDF).
• Running capture at shift (slow) timing. Delay faults need at-speed capture.
• Forgetting shift-out overlaps shift-in of the next pattern.

8. Industry Best Practices

• Keep SE stable (low) across the capture edge — no glitch, settled early.
• Capture at functional (at-speed) timing (SDF); shift can be slow.
• Distinguish protocol/SE bugs from pattern bugs.
• Overlap shift-out with shift-in of the next pattern (efficiency).
• Verify shift/capture in GLS before the tester.

Senior Engineer Thinking

• Beginner: "These patterns mismatch — regenerate them."
• Senior: "Is the SE stable at capture? A glitch there captures scan data, not the response — the patterns are fine. And is capture at functional (at-speed) timing so the response settled? Those are protocol issues, not pattern issues."

The senior checks SE stability and capture timing before blaming the patterns.

Silicon Impact

Shift and capture are the heartbeat of scan test, and their control — especially SE stability at capture — is where subtle, pattern-independent failures hide. A glitchy SE at the capture edge causes wrong-mode captures and mismatches on the tester that look like bad patterns, derailing bring-up while engineers regenerate vectors that were never the problem (0.3). And because capture uses functional (at-speed) timing, a capture-clock timing error (capturing before the path settles) causes real mismatches too. GLS simulates both modes with real timing, catching these protocol bugs before silicon. Getting the shift/capture protocol right — stable SE, correct capture timing — is what makes ATPG patterns (11.4) actually apply correctly on the tester.

Engineering Checklist

• SE stable (low) across the capture edge (no glitch, settled early).
• Capture at functional (at-speed) timing (SDF); shift slow.
• Distinguished protocol/SE bugs from pattern bugs.
• Overlapped shift-out with shift-in of the next pattern.
• Verified shift/capture in GLS before the tester.

Try Yourself

1. Simulate a scan cycle: shift in (SE = 1), capture (SE = 0, one functional clock), shift out (SE = 1), with SE stable at capture.
2. Observe: the flops capture the functional response; scan-out matches expected.
3. Change: glitch SE (briefly high) at the capture edge.
4. Expect: some flops capture scan data instead → mismatch — with the same pattern. Restore stable SE to fix. Prove it was protocol, not pattern.

Any free Verilog simulator with scan-flop cells reproduces shift/capture and SE-glitch mismatches. No paid tool required.

Interview Perspective

• Weak: "Scan just shifts data in and out."
• Good: "Shift (SE = 1) loads/reads the chain; capture (SE = 0, one functional clock) captures the response; then shift out and compare."
• Senior: "A scan cycle is shift-in, capture, shift-out/compare. The SE must be stable across the capture edge — a glitch there captures scan data instead of the response, a mismatch that looks like a bad pattern. Capture uses functional (at-speed) timing while shift is slow. GLS simulates both modes with real timing; coverage is ATPG's."

9. Interview / Review Questions

10. Key Takeaways

• A scan test has two modes: shift (SE = 1, data moves bit-by-bit through the chain, scan-in → scan-out) and capture (SE = 0, one functional clock captures the combinational response to the loaded pattern).
• The test cycle is: shift in a pattern → capture the response (one functional clock) → shift out and compare (overlapped with loading the next pattern).
• The SE must be stable (low) across the capture edge — a glitch/late transition puts flops in the wrong mode, capturing scan data instead of the response → mismatch (looks like a bad pattern, but it's a protocol bug).
• Capture uses functional (at-speed) timing (the real combinational path, SDF), while shift is typically slow.
• GLS simulates shift/capture behaviour with real timing; fault coverage is ATPG's (11.1); GLS stays dynamic, STA signs off timing (0.3). Next: 11.4 — ATPG pattern GLS & mismatch debug.

Quick Revision

Scan cycle: SHIFT (SE=1, load/read chain bit-by-bit) → CAPTURE (SE=0, one functional clock captures the response) → SHIFT OUT + compare (overlap next load). SE must be STABLE across the capture edge — glitch → wrong mode → captures scan data → mismatch (protocol bug, not pattern). Capture = functional (at-speed) timing (SDF); shift = slow. GLS verifies behaviour, not coverage. Next: 11.4 — ATPG pattern GLS & mismatch debug.