Test Modes: Scan, Capture, BIST & Functional

Chapter 11 · Section 11.1 · Test Modes & DFT Signals

Project thread — the mini-SoC (scan/ATPG + MBIST + LBIST + boundary scan) must be steered cleanly between its modes; 11.5 shows the full control on a clock-gated block.

1. Why Should I Learn This?

The mode organization is what lets all the DFT you've learned coexist on one chip — a top-level architecture concern.

• A chip lives in modes: functional, scan-shift, capture, BIST (MBIST/LBIST), boundary-scan.
• Each mode = a combination of control signals (test-mode, scan-enable, BIST-enable, TAP instruction).
• Each needs different clocking, reset, and data paths — organized, not ad-hoc.
• The mode map must be clean: one mode at a time, deterministic selection, known default.

2. Real Silicon Story — two modes on at once

A chip's bring-up hit bizarre, non-deterministic test failures — sometimes scan worked, sometimes it produced garbage, and there were signs of clock conflicts. The scan logic, the BIST, and the boundary scan were each fine in isolation; the problem appeared only on the real chip.

The root cause was a disorganized mode map. The test controls (scan-enable, BIST-enable, a test-mode pin) were not mutually exclusive — a particular combination left both scan-shift and BIST 'partly on' at once, so the design was driven by two conflicting clock sources and two data paths simultaneously → undefined behavior. There was no clean decode ensuring exactly one mode and a known default; the modes had grown ad-hoc as features were added.

The fix was architectural: define a clean mode map — a decoder that makes the modes mutually exclusive, selects exactly one at a time from a defined combination of controls, and defaults to functional — so scan, BIST, and boundary scan never fight. Lesson: the modes must be organized as a top-level architecture — one mode active at a time, deterministically selected — or the chip does something undefined when the controls overlap.

3. Factory Perspective — test modes through each lens

• What the test engineer sees: a mode map — which control-signal combination puts the chip in scan-shift / capture / MBIST / LBIST / EXTEST — and drives it via pins/TAP for each test.
• What the DFT engineer sees: the modes as a top-level control architecture to design — mutually exclusive, decoded, default functional.
• What the RTL/DV engineer sees: that their logic must behave correctly in every mode (clocking/reset/data change per mode) — a multi-mode design requirement.
• What management cares about: that a clean mode organization is what makes the DFT investment (scan/BIST/boundary scan) usable together — the difference between DFT that works and DFT that conflicts.

4. Concept — the modes and their defining controls

Functional (mission) mode:

• Normal operation — the design does its job; test logic transparent/off (scan cells transparent, boundary cells transparent, BIST idle).
• Default mode — the chip powers up functional.

Scan-shift mode:

• scan-enable = 1; slow shift clock; the scan chains load/unload patterns (3.4). Data path = the scan chain.

Capture mode:

• scan-enable = 0; functional or at-speed clock (via OCC, 2.3); one capture — the logic responds and is captured (3.4). Scan test = alternate shift ↔ capture.

BIST modes:

• MBIST (bist-enable for memory): the MBIST controller runs a March test at-speed (8.4).
• LBIST (logic BIST): the PRPG/MISR self-test runs (9.2). Data path = on-chip generated; result = signature.

Boundary-scan (JTAG) modes:

• EXTEST / SAMPLE / etc. via the TAP instruction (Chapter 10) — boundary cells drive/observe pins.

Each mode = a combination of control signals:

• test-mode (are we in test at all?), scan-enable (shift vs capture), BIST-enable (MBIST/LBIST), the TAP instruction (boundary scan).
• The combination selects the mode; the modes must be mutually exclusive and deterministically decoded.

Why organization matters (each mode differs in):

• Clocking: shift clock (scan-shift) vs functional/at-speed (capture) vs BIST clock — must be cleanly switched (11.3).
• Reset: async resets gated off in test (4.4) — different from functional.
• Data paths: functional vs scan vs BIST vs boundary — muxed per mode (11.2).

The mode map (top-level architecture):

• A clean, unambiguous map: one mode at a time, deterministic selection, known default (functional) — the foundation the whole chapter builds on.

5. Mental Model — a machine with a mode dial

A DFT-equipped chip is like a complex machine with a mode dial — each setting reconfigures how it runs.

• Functional is 'normal use' — the machine does its job; all the test rigging is out of the way (transparent). It's the default you return to.
• Scan-shift is 'load the test fixture' — the machine slowly threads material through its test slots (shift clock, scan-enable on).
• Capture is 'run one step and record' — a single, precise operation at full speed, results latched.
• BIST is 'self-diagnostic' — the machine runs its own built-in test routine and reports a summary (signature).
• Boundary-scan is 'inspect the connections' — it exercises its ports to check the wiring around it.
• The dial must click firmly into one setting at a time — you can't be half in 'normal use' and half in 'self-diagnostic', or the machine tears itself in two directions (conflicting clocks/data). A well-built dial has detents (mutually exclusive positions) and a home position (default functional).

One mode dial, firm detents, a home position — the machine reconfigures cleanly for each job instead of fighting itself.

6. Working Example — the mode map

Define the mini-SoC's mode map (which controls select each mode):

# Test-mode map - REPRESENTATIVE, SIMPLIFIED, tool-neutral (mini-SoC):
  MODE           test_mode  scan_enable  bist_enable  TAP instr   CLOCK           RESET        DATA PATH
  FUNCTIONAL      0          x            0            (normal)    functional      functional   functional  (DEFAULT)
  SCAN-SHIFT      1          1            0            -           SHIFT (slow)    gated off     scan chain
  CAPTURE         1          0            0            -           func/at-speed   gated off     functional (captured)
  MBIST           1          x            1 (mem)      -           BIST/at-speed   gated off     MBIST-generated
  LBIST           1          x            1 (logic)    -           BIST/at-speed   gated off     PRPG/MISR
  BOUNDARY-SCAN   1          x            0            EXTEST/...  TCK-driven      controlled    boundary cells
# Each mode = a COMBINATION of controls. Selection must be MUTUALLY EXCLUSIVE + deterministic (one mode at a time).
# WRONG: scan_enable=1 AND bist_enable=1 -> two modes 'partly on' -> conflicting clocks/data -> UNDEFINED behavior.

7. Industry Flow — steering the chip between modes

A device is steered through its modes for each test, from a clean mode map:

8. Debugging Session — ambiguous mode selection

9. Common Mistakes

• Ad-hoc, overlapping mode controls. Modes must be mutually exclusive — decode them cleanly (one at a time).
• No known default. The chip must default to functional — a defined home mode.
• Assuming per-mechanism correctness = integrated correctness. Each mode works alone; the organization can still conflict.
• Ignoring per-mode clock/reset/data differences. Each mode needs its own coherent configuration (11.2/11.3).
• Letting modes grow feature-by-feature. Design the mode map up front — a top-level architecture concern.

10. Industry Best Practices

• Design a clean mode map up front — modes as a top-level control architecture.
• Make modes mutually exclusive + deterministically decoded — exactly one active, defined priority/default.
• Default to functional — a known home mode at power-up.
• Route per-mode clock/reset/data from a mode decoder (11.2) — coherent per mode.
• Verify mode exclusivity — no combination yields two active modes.

11. Senior Engineer Thinking

• Beginner: "Scan, BIST, and boundary scan each work — the chip's DFT is done."
• Senior: "Each works alone — but are the modes mutually exclusive? If a control combination leaves two modes partly on, I get conflicting clocks/data and undefined behavior. I design a clean mode map: a decoder that makes selection one-hot with a functional default, and route per-mode clock/reset/data from it. Mode organization is top-level architecture, not a per-block afterthought."

The senior treats the mode map as top-level architecture — mutually exclusive, deterministic, default functional.

12. Silicon Impact

Test-mode organization is the integration layer that makes everything in the previous ten chapters actually work together on one chip. Individually, scan, ATPG, MBIST, LBIST, and boundary scan are each correct — but they each demand a different clocking, reset, and data-path configuration, so the chip must be steered between distinct modes, and how that steering is organized is a top-level architecture decision, not a per-block detail. The defining insight is that each mode is a combination of control signals (test-mode, scan-enable, BIST-enable, TAP instruction), and the modes must be mutually exclusive and deterministically decoded — exactly one active at a time, with a known default (functional) — because overlapping control combinations leave two modes 'partly on' and drive the design with conflicting clocks and data paths, producing undefined, non-deterministic behavior that appears only on the integrated chip (the story) and is maddening to debug precisely because every mechanism works in isolation. This is why a clean mode map — a top-level mode decoder producing one-hot selection with a defined priority and functional default — is a first-class deliverable: it's the contract that lets test/system engineers drive the right mode for each test, that RTL/DV design against for multi-mode correctness, and that verification checks for exclusivity. Get it right and the chip cleanly reconfigures for scan, capture, BIST, and board test on command; get it wrong — let the modes grow ad-hoc feature-by-feature — and the DFT fights itself. For the DFT engineer, the mode map is the backbone the rest of the chapter builds out — the muxing that implements it (11.2), the big-three signals it routes (11.3), the isolation it enables (11.4), and a worked example (11.5) — and it's what the DFT timing/constraints of Chapter 12 must ultimately constrain and time.

13. Engineering Checklist

• Defined a test-mode map (functional/scan-shift/capture/MBIST/LBIST/boundary-scan) with the control combination for each.
• Made modes mutually exclusive and deterministically decoded (one active at a time; defined priority).
• Set a known default (functional) at power-up.
• Ensured per-mode clock/reset/data are coherent (routed from the mode decoder, 11.2).
• Verified mode exclusivity — no control combination yields two active modes.

14. Try Yourself

1. List the modes (functional/scan-shift/capture/MBIST/LBIST/boundary-scan) and the control combination for each.
2. Build a mode-map table (test-mode/scan-enable/BIST-enable/TAP instruction → clock/reset/data).
3. Show an illegal combination (e.g. scan-enable=1 AND BIST-enable=1) and the conflict it causes.
4. Add a mode decoder that makes selection one-hot with a functional default — resolve the illegal combination.
5. Explain why each mechanism working alone doesn't guarantee integrated correctness (mode organization).

The mode map is tool-neutral; it's a design/architecture artifact. No paid tool required to reason about modes.

15. Interview Perspective

• Weak: "The chip has a test mode and a functional mode."
• Good: "It has functional, scan-shift, capture, BIST, and boundary-scan modes, each with different controls."
• Senior: "A chip lives in several modes — functional (default), scan-shift (scan-enable=1, shift clock), capture (scan-enable=0, functional/at-speed clock), MBIST/LBIST (BIST-enable), and boundary-scan (TAP instruction). Each is a combination of control signals and needs different clocking, reset, and data paths. The key is organization: the modes must be mutually exclusive and deterministically decoded — exactly one active at a time, with a known default (functional) — or an overlapping combination leaves two modes partly on, driving conflicting clocks/data → undefined behavior that shows up only on the integrated chip while each mechanism works alone. So I design a clean mode map (a top-level decoder) up front — it's architecture, not a per-block afterthought."

16. Interview / Review Questions

17. Key Takeaways

• A DFT-equipped chip lives in several modes — functional (default), scan-shift, capture, BIST (MBIST/LBIST), and boundary-scan — each a different way of clocking, resetting, and routing data.
• Each mode is defined by a combination of test control signals: test-mode, scan-enable (shift vs capture), BIST-enable (MBIST/LBIST), and the TAP instruction (boundary scan).
• Organizing the modes is a top-level architecture concern — the mode map must be clean: mutually exclusive, deterministically decoded, exactly one active at a time, with a known default (functional).
• Disorganized modes (overlapping controls) leave two modes 'partly on' → conflicting clocks/data → undefined, non-deterministic behavior that appears only on the integrated chip while each mechanism works in isolation.
• A well-defined mode map is what makes scan, ATPG, BIST, and boundary scan coexist on one chip — the backbone for the muxing (11.2), big-three signals (11.3), isolation (11.4), and worked example (11.5) that follow. Next: 11.2 — test-mode control & signal muxing.

18. Quick Revision

Test modes (Ch11 opener). A chip lives in MODES, each = a COMBINATION of control signals + its own clocking/reset/data: FUNCTIONAL (default, test off), SCAN-SHIFT (scan_enable=1, shift clock, load/unload chains), CAPTURE (scan_enable=0, functional/at-speed clock, one capture), MBIST/LBIST (bist_enable, on-chip self-test), BOUNDARY-SCAN (TAP instruction EXTEST/SAMPLE). Organizing them = a top-level ARCHITECTURE concern: the mode map must be MUTUALLY EXCLUSIVE + deterministically decoded (exactly ONE active at a time, known DEFAULT = functional). Overlapping controls (e.g. scan_enable=1 AND bist_enable=1) → two modes 'partly on' → conflicting clocks/data → UNDEFINED behavior (shows up only integrated, while each mechanism works alone). A clean mode map makes scan/ATPG/BIST/boundary scan coexist. Next: 11.2 — test-mode control & signal muxing.