Test-Mode Control & Signal Muxing

Chapter 11 · Section 11.2 · Test Modes & DFT Signals

Project thread — the mini-SoC's mode decoder (driven by the TAP, Ch10) generates the per-block clock/reset/data mux controls; 11.5 shows it on a clock-gated block.

1. Why Should I Learn This?

The muxing is how the mode map (11.1) becomes hardware — control signals steer clock/reset/data muxes, organized by a decoder.

• A mode decoder (driven by TAP/test pins) → per-block control signals → muxes for clock/reset/data.
• Clock muxes must be glitch-free — a glitch = a spurious edge = corrupted state (use OCC / glitch-free mux).
• Mode signals are static (set per mode); scan-enable is dynamic (per cycle, 3.4) — don't confuse them.
• Muxing costs area/delay (like scan's mux, 3.2) — budget it; organized decode beats ad-hoc signals.

2. Real Silicon Story — the clock mux that glitched

A chip switched between the functional clock and the shift clock with a plain combinational mux (a 2:1 selecting the clock by a test-mode signal). It simulated fine — but on silicon, switching modes occasionally corrupted the loaded scan state, non-deterministically.

The bug was the clock mux itself. When a combinational mux switches its select while both clock inputs are toggling, the output can produce a runt / spurious edge during the transition — a glitch. On a clock, a glitch is catastrophic: it's a spurious edge that clocks the flops when they shouldn't be clocked, corrupting the carefully-loaded scan state. Because it depended on the exact phase alignment at the switch, it was intermittent.

The fix was a glitch-free clock mux (or OCC): a small circuit that switches clocks only on safe edges, guaranteeing no spurious edge during the changeover. Lesson: clocks are special — a plain mux on a clock can glitch, and a glitch on a clock is a spurious edge that corrupts state, so clock selection must be glitch-free (a glitch-free clock mux / OCC), never a naive combinational mux.

3. Factory Perspective — muxing through each lens

• What the DFT engineer sees: a mode decoder generating per-block controls driving clock/reset/data muxes — with glitch-free clock muxing (OCC) and static mode signals.
• What the CTS/physical engineer sees: the clock muxes as timing- and **glitch-**critical — glitch-free selection, careful clock-path timing.
• What the RTL/DV engineer sees: the muxes on functional paths to budget (delay), and that mode signals are static (don't toggle mid-test) while scan-enable is dynamic.
• What management cares about: that organized control (a decoder) is coherent and verifiable — versus ad-hoc test signals that cause mode conflicts and glitch bugs (schedule risk).

4. Concept — the decoder, the muxes, and the four properties

Control hierarchy — the mode decoder:

• A top-level mode decoder / test controller takes the raw controls (test-mode, scan-enable, BIST-enable, TAP instruction) — often from the TAP (Chapter 10) or test pins — and produces the per-block control signals (one-hot mode, plus specific mux selects).
• This hierarchy (decoder → named per-block signals) is what keeps control coherent (versus ad-hoc, 11.1).

What gets muxed (the per-mode differences, 11.1):

• Clocks: functional clock vs shift clock (slow) vs BIST clock vs at-speed capture — via OCC / glitch-free clock mux.
• Resets: functional reset vs gated-off-in-test (4.4).
• Data: functional data vs scan-in vs BIST-generated.
• Enables: clock-gate test-enable (4.4), isolation controls (11.4), etc.

Property 1 — clock muxes must be glitch-free:

• A glitch on a clock = a spurious edge → clocks flops unexpectedly → corrupts state (the story).
• Use a glitch-free clock mux (switches only on safe edges) or OCC — never a plain combinational mux for a clock.

Property 2 — static vs dynamic controls:

• Mode signals (test-mode) are slow/static — set once per mode, held stable during the test.
• scan-enable is dynamic — toggles every shift/capture (3.4). Don't change a static mode signal mid-shift (breaks the test).

Property 3 — muxing costs area and delay:

• Every functional-path mux adds delay (like scan's mux, 3.2) — budget it; clock-path muxes are especially timing-sensitive.

Property 4 — organized beats ad-hoc:

• A decoder → named signals structure is coherent, verifiable, and mutually exclusive (11.1) — versus test signals sprinkled through the design, which cause conflicts and glitches.

5. Mental Model — a stage crew switching sets on cues

The mode decoder + muxing is like a stage crew reconfiguring a theater for different acts (modes) on cues (control signals).

• The stage manager (mode decoder) reads the cue sheet (the controls, from the TAP/pins) and issues specific instructions to each crew station (per-block controls) — one coherent plan, not everyone improvising (ad-hoc).
• Each station swaps its piece — the lighting (clock), the safety systems (reset), the props (data) — to match the act.
• The lighting board (clock mux) is special: you can't just yank the master switch mid-scene — you'd get a flicker (glitch) that ruins the take. So you switch lights only on a blackout (a glitch-free changeover / OCC).
• Some cues are 'set once per act' (static mode signals — the set stays put through the act); others are 'every beat' (dynamic — like scan-enable toggling each cycle). The crew mustn't restrike the set mid-scene.
• Every added swap mechanism has a little overhead (area/delay) — you plan for it.

A stage manager issuing coherent cues to each station, switching lights only on a blackout — that's organized, glitch-free mode muxing.

6. Working Example — the mode decoder and its muxes

Sketch the decoder generating per-block mux controls:

// SystemVerilog - a simple mode decoder + the muxes it drives (STRUCTURE; representative)
module mode_control (
  input  logic test_mode, scan_enable, bist_enable,   // raw controls (from TAP/pins)
  // per-block control OUTPUTS (one coherent decode)
  output logic use_shift_clk, use_bist_clk,           // clock mux selects (glitch-free mux downstream!)
  output logic reset_gate,                             // 1 = gate reset OFF in test (4.4)
  output logic scan_data_sel                           // 1 = scan-in path, else functional
);
  // static mode signals decoded coherently (mutually exclusive per 11.1)
  assign use_bist_clk  = test_mode &  bist_enable;                 // BIST mode
  assign use_shift_clk = test_mode & ~bist_enable &  scan_enable;  // scan-shift (slow clock)
  // capture uses the functional/at-speed clock (neither shift nor BIST)
  assign reset_gate    = test_mode;                               // gate reset off in any test mode (4.4)
  assign scan_data_sel = test_mode & ~bist_enable &  scan_enable;  // scan path during shift
endmodule

# The muxes these controls steer - REPRESENTATIVE, SIMPLIFIED, tool-neutral:
  CLOCK:  select functional / shift / BIST / at-speed  -> via a GLITCH-FREE clock mux / OCC (NOT a plain mux!)
          (a glitch on a clock = a spurious edge = corrupted state)
  RESET:  reset_gate -> gate the async reset OFF in test (4.4)
  DATA:   scan_data_sel -> scan-in path (shift) vs functional data
  NOTE:   test_mode / bist_enable are STATIC (set once per mode) ; scan_enable is DYNAMIC (per shift/capture, 3.4)
          the muxes add DELAY on their paths (like scan's mux, 3.2) -> budget it (clock muxes especially).

7. Industry Flow — decode then mux, coherently

The controls flow through a decoder into per-mode muxing:

8. Debugging Session — switching modes glitches the clock

9. Common Mistakes

• Muxing a clock with a plain mux. It glitches (spurious edge → corrupted state) — use a glitch-free clock mux / OCC.
• Changing a static mode signal mid-test. Mode signals are static (set per mode); only scan-enable is dynamic (3.4).
• Ignoring mux delay. Functional-path muxes add delay (like scan's mux, 3.2) — budget it (clock muxes especially).
• Ad-hoc test signals. Use a decoder → named per-block signals — coherent and mutually exclusive (11.1).
• Forgetting reset gating in the mux set. Async resets must be gated off in test (4.4) — part of the muxing.

10. Industry Best Practices

• Use a top-level mode decoder → named per-block controls (coherent, verifiable, mutually exclusive).
• Switch clocks glitch-free (glitch-free clock mux / OCC) — never a naive combinational mux.
• Keep mode signals static, scan-enable dynamic — don't confuse the two.
• Budget mux area/delay on functional and clock paths (like scan's mux, 3.2).
• Route reset gating (4.4) and isolation (11.4) from the same decoder.

11. Senior Engineer Thinking

• Beginner: "Switching modes corrupts scan — must be a scan or timing bug."
• Senior: "How is the clock selected? A plain mux on a clock glitches at the switch — a spurious edge that clocks the flops and corrupts state. Clocks are special: I use a glitch-free clock mux / OCC that switches only on safe edges. And I generate all the mux selects from a coherent mode decoder — no ad-hoc signals. Clocks don't get naive muxes."

The senior switches clocks glitch-free and routes muxes from a coherent decoder — never a naive clock mux.

12. Silicon Impact

Signal muxing is how the abstract mode map (11.1) becomes real, reliable silicon, and it introduces one hazard that is uniquely dangerous and one organizing principle that is uniquely valuable. The hazard is clock muxing: because a glitch on a clock is a spurious edge — and an edge clocks every flop on that clock — a plain combinational mux selecting a clock can, at the moment its select changes, produce a runt pulse that clocks the flops unexpectedly and corrupts state, intermittently and non-deterministically (the story). The only correct way to switch clocks is a glitch-free clock mux or OCC that changes the clock only on safe edges — a rule so important it separates working DFT from a maddening intermittent bug. The organizing principle is the mode decoder: rather than sprinkle ad-hoc test signals through the design (which causes the mode conflicts of 11.1), a top-level decoder takes the raw controls (from the TAP or test pins) and generates coherent, mutually-exclusive, named per-block signals that steer the clock/reset/data muxes — control that is verifiable and conflict-free. Two further disciplines round it out: static vs dynamic controls (mode signals set once per mode and held stable, versus scan-enable toggling every cycle, 3.4 — confusing them breaks the test), and budgeting the mux area/delay (every functional-path mux costs timing like scan's mux, 3.2, with clock-path muxes especially sensitive). For the DFT engineer, the decoder + glitch-free clock muxing is the implementation backbone of the mode map; for the CTS/physical engineer, the clock muxes are timing- and glitch-critical; and for the RTL/DV engineer, the muxes on their paths and the static-control discipline are integration requirements. This is what makes the mode map steer cleanly, and it's the mechanism that routes the big-three test signals (11.3), enables isolation (11.4), and controls the clock-gated block (11.5) — all of which Chapter 12 must then constrain and time.

13. Engineering Checklist

• Built a top-level mode decoder → coherent per-block control signals (mutually exclusive, 11.1).
• Switched clocks glitch-free (glitch-free clock mux / OCC) — no naive combinational clock mux.
• Kept mode signals static, scan-enable dynamic; didn't change static signals mid-test.
• Budgeted mux area/delay on functional and clock paths (like scan's mux, 3.2).
• Routed reset gating (4.4) and isolation (11.4) from the same decoder.

14. Try Yourself

1. Sketch a mode decoder taking test_mode/scan_enable/bist_enable → per-block controls (clock/reset/data selects).
2. Show the clock mux it drives, and why it must be glitch-free (a glitch = a spurious edge).
3. Distinguish static mode signals from the dynamic scan-enable (per cycle, 3.4).
4. Add the reset gate (4.4) to the muxing; explain gating reset off in test.
5. Explain why organized decode (named signals) beats ad-hoc test signals (11.1 conflicts).

The structure is tool-neutral; glitch-free clock muxing/OCC are standard. No paid tool required to reason about the muxing.

15. Interview Perspective

• Weak: "A test-mode signal switches the design into test."
• Good: "Control signals mux the clocks, resets, and data between functional and test paths."
• Senior: "Modes are implemented by control signals steering muxes — for clocks (functional/shift/BIST/at-speed), resets (gated off in test, 4.4), and data (scan/BIST/functional) — generated by a top-level mode decoder (from the TAP or test pins) as coherent, mutually-exclusive per-block signals. The critical rule: clock muxes must be glitch-free — a glitch on a clock is a spurious edge that clocks the flops and corrupts state, so I use a glitch-free clock mux / OCC, never a plain combinational mux. Mode signals are static (set per mode), scan-enable is dynamic (per cycle, 3.4) — don't confuse them. The muxes cost area/delay (like scan's mux, 3.2), so I budget them. Organized decode beats ad-hoc test signals — it's coherent and verifiable."

16. Interview / Review Questions

17. Key Takeaways

• Test modes are implemented by control signals that steer muxes selecting functional vs test paths — for clocks (functional/shift/BIST/at-speed via OCC), resets (gated-off-in-test, 4.4), and data (functional/scan-in/BIST).
• Control is organized as a hierarchy: a top-level mode decoder / test controller (driven by the TAP or test pins) generates coherent, mutually-exclusive, named per-block control signals — versus ad-hoc test signals (the 11.1 conflict source).
• Clock muxes must be glitch-free: a glitch on a clock is a spurious edge that clocks the flops and corrupts state, so use a glitch-free clock mux or OCC (switch only on safe edges) — never a plain combinational mux for a clock.
• Mode signals are static (set once per mode, held stable); scan-enable is dynamic (toggles every shift/capture, 3.4) — don't confuse them; and muxing adds area/delay (like scan's mux, 3.2) to budget (clock muxes especially).
• Organized, glitch-free muxing is what turns the mode map (11.1) into reliable silicon — the backbone that routes the big-three signals (11.3), enables isolation (11.4), and controls the clock-gated block (11.5). Next: 11.3 — scan-enable, test-clock & reset control.

18. Quick Revision

Test-mode control & muxing. Modes are implemented by control signals steering MUXES (functional vs test): CLOCK (functional/shift/BIST/at-speed), RESET (gated-off in test, 4.4), DATA (functional/scan-in/BIST). A top-level MODE DECODER (from the TAP Ch10 / test pins) generates coherent, mutually-exclusive per-block controls (vs ad-hoc → 11.1 conflicts). CLOCK MUXES MUST BE GLITCH-FREE: a glitch on a clock = a SPURIOUS EDGE → clocks the flops → corrupts state → use a glitch-free clock mux / OCC (switch only on safe edges), NEVER a plain mux. Mode signals STATIC (set per mode) vs scan_enable DYNAMIC (per cycle, 3.4). Muxes add area/delay (like scan's mux, 3.2) → budget. Next: 11.3 — scan-enable, test-clock & reset control.