DFT · Chapter 11 · Test Modes & DFT Signals
Isolating Functional Logic in Test
When you put a block into test mode, you often must isolate it from the rest of the chip, or the rest from it, and this lesson organizes why and how. There are three motivations. First, stop X-injection: analog, non-scan, IP, and memory blocks cannot be scan-tested and their outputs are unknown, so you drive their digital-facing interfaces to known values in test to keep them from corrupting the scan compactor or the LBIST signature register. Second, protect neighbors: a block's outputs during its own scan test are arbitrary, so you safe-state them to avoid bus contention, disturbance, or damage. Third, test cores independently by wrapping a core with wrapper boundary cells, the IEEE 1500 core-test-wrapper idea. The mechanism throughout is test-mode isolation muxes and gates that drive known values or disable drivers.
Intermediate13 min readDFTIsolationCore WrapperIEEE 1500X-Sources
Chapter 11 · Section 11.4 · Test Modes & DFT Signals
Project thread — the mini-SoC isolates its analog interface (and memory, 8.6) in test so they don't inject X; 11.5 shows isolation on a clock-gated block.
1. Why Should I Learn This?
Isolation is what lets a multi-block SoC be tested block by block without blocks corrupting each other's tests — no X-injection, no contention.
- Isolate analog/non-scan/IP/memory: drive their interfaces to known values → no X into the compactor/MISR (7.4/9.4).
- Safe-state a block's outputs: don't disturb neighbors / cause contention or damage.
- Core wrappers (IEEE 1500): wrap a core for independent, isolated per-core test.
- Mechanism: test-mode isolation muxes/gates driving known values / disabling drivers.
2. Real Silicon Story — the analog block that flooded the compactor
A mixed-signal SoC's digital scan coverage was stubbornly low, with heavy X-masking (7.4) concentrated near an analog block's digital interface. The team assumed the digital logic was hard to test.
It wasn't. The analog block — which can't be scan-tested — was driving unknown (X) values onto its digital-facing outputs during the scan test, and those X's flowed into the scan compactor, forcing heavy masking and dropping coverage across the region — exactly the memory X-source problem of 7.5, but from an analog block. The analog block wasn't isolated from the digital test.
The fix was isolation: drive the analog block's digital-facing interface to known values in test mode (an isolation mux to a constant), so it stopped injecting X. The masking shrank, and digital coverage recovered. Lesson: a non-scan/analog/IP block that isn't isolated injects X into the digital test (compactor/MISR), just like an un-bypassed memory (7.5/8.6) — so isolate it (drive its interface to known values in test), and the coverage it was stealing comes back.
3. Factory Perspective — isolation through each lens
- What the DFT engineer sees: isolation muxes/gates at block boundaries (drive-known / disable-drivers), plus core wrappers (IEEE 1500) for independent core test — all mode-decoder-driven (11.2).
- What the test engineer sees: clean scan/BIST coverage (no X-injection) and safe operation (no contention/damage) — and per-core test.
- What the analog/IP/RTL engineer sees: that their block's digital interface must be isolatable (bypass to known values) and its outputs safe-stated in test — an integration requirement.
- What management cares about: that isolation recovers coverage (X-injection) and enables independent core test — testability and protecting the device during test.
4. Concept — the three isolation jobs and the mechanism
Job 1 — stop X-injection (into scan compactor / LBIST MISR):
- Analog, non-scan, IP, memory blocks can't be scan-tested → their outputs are X during scan.
- Unisolated, those X's flow into the scan compactor (7.4) or the MISR (9.4) → masking/coverage loss (compactor) or a corrupt signature (MISR).
- Isolate: drive their digital-facing interfaces to known values in test → no X injected. (The memory bypass of 8.6 generalized.)
Job 2 — don't disturb neighbors / protect the chip:
- A block's outputs during its own scan test are arbitrary (scan-driven, not functional).
- Unmanaged, they can drive shared buses/off-chip → contention, disturb a neighbor's test, or damage the device.
- Safe-state: drive the block's outputs to a defined, harmless value or disable the drivers in test.
Job 3 — independent, isolated per-core test (core wrappers):
- Wrap a core with wrapper boundary cells — analogous to boundary scan but around a core — so it can be tested independently and isolated from neighbors.
- This is the IEEE 1500 core-test-wrapper idea (the core-level cousin of 1149.1, Chapter 10) — enabling per-core test + isolation in a large SoC.
The mechanism (common to all three):
- Test-mode-controlled isolation muxes/gates at block boundaries — drive known values (kill X) or disable drivers (safe-state) — steered by the mode decoder (11.2).
5. Mental Model — sealing off rooms during a renovation
Isolation is like sealing off certain rooms while you renovate and inspect a building room by room.
- Some rooms have hazardous, unpredictable contents (an analog/IP block producing X) — you seal their doorways with a known barrier so their mess doesn't spill into the rooms you're inspecting (no X into the compactor/MISR).
- The room you're working on might swing tools around (its scan-driven outputs) — you cap its shared pipes/wires so it doesn't flood the neighbors or short the mains (safe-state: no contention/damage).
- To renovate a room independently, you build a temporary enclosure around it (a core wrapper) so you can work inside without affecting — or being affected by — the rest of the building (IEEE 1500 independent core test).
- All the seals are controlled from the site office (the mode decoder), put up only during work (test mode) and taken down for normal use (functional mode).
Seal the hazardous rooms, cap the working room's shared lines, and enclose a room to work independently — that's isolation: test each block without them spilling into each other.
6. Working Example — isolating an analog interface
Isolate a non-scan block so it doesn't inject X or disturb neighbors:
# Isolating a non-scan / analog / IP block in test - REPRESENTATIVE, SIMPLIFIED, tool-neutral:
PROBLEM (unisolated): the analog block's digital outputs = X in scan -> flood the compactor -> heavy masking ->
digital coverage LOW (7.4/9.4) ; its outputs may also drive shared buses -> contention.
ISOLATE (test mode, from the mode decoder 11.2):
at the block's DIGITAL-FACING interface: MUX its outputs to KNOWN values in test -> no X into the compactor/MISR
at the block's SHARED-BUS / off-chip drivers: DISABLE or SAFE-STATE them in test -> no contention / no damage
RESULT: no X-injection -> masking shrinks -> digital coverage RECOVERS ; no contention -> safe test.
# Same idea as bypassing the MEMORY in scan (8.6), generalized to analog/IP. For CORES: an IEEE-1500 WRAPPER isolates
# the core (wrapper boundary cells) -> test it INDEPENDENTLY, isolated from neighbors.7. Industry Flow — isolate boundaries, then test blocks cleanly
Isolation at block boundaries enables clean, independent block-by-block test:
8. Debugging Session — coverage hurt near a non-scan IP
Digital scan coverage is low with heavy X-masking concentrated near an analog or non-scan IP interface, and the team assumes the digital logic is hard to test; the analog/IP block can't be scan-tested and is injecting X onto its digital outputs into the scan compactor, so the fix is to isolate it by driving its digital-facing interface to known values in test, after which the masking shrinks and coverage recovers
A NON-SCAN / ANALOG BLOCK INJECTS X UNLESS ISOLATED — DRIVE ITS INTERFACE TO KNOWN VALUESDigital scan coverage is low, with heavy X-masking (7.4) concentrated near an analog / non-scan IP interface. The team assumes the digital logic is inherently hard to test.
The analog / non-scan IP block can't be scan-tested, so its digital-facing outputs are unknown (X) during the scan test, and because it isn't isolated, those X's flow into the scan compactor and force heavy masking that drops coverage across the region. Scan/ATPG only works on scan-testable digital logic; an analog block (or a non-scan IP / memory) has no scan chain and produces unknown (X) on its outputs during a scan test (its behavior isn't modeled by the digital test). If that block's digital-facing outputs feed digital logic that is scanned, the X propagates into the scan compactor, and — exactly as in 7.4/7.5 — the flow masks the X-carrying chains, which also masks the real fault effects on them, throwing away coverage in the affected region. The masking report shows the loss concentrated at the analog/IP interface — the tell that an X-source, not hard digital logic, is the cause. The block isn't 'hard to test'; it's injecting X into the digital test because it isn't isolated — the same mechanism as an un-bypassed memory (7.5/8.6), now from an analog/IP block.
Isolate the non-scan block — drive its digital-facing interface to known values in test mode — so it stops injecting X, and the masking shrinks and coverage recovers. Add a test-mode isolation mux at the block's digital-facing outputs (steered by the mode decoder, 11.2) that drives them to known constant values during the scan test, so the downstream digital logic sees defined (not X) inputs and the X never reaches the compactor. (Also safe-state any of its shared-bus/off-chip drivers to avoid contention.) Re-run: the masking around the interface shrinks, and the digital coverage recovers — the coverage the un-isolated block was stealing comes back. For cores, use an IEEE 1500 wrapper so the core is isolated and independently testable. The principle to lock in: blocks that cannot be scan-tested — analog, non-scan IP, and memory — produce unknown (X) outputs during a scan test, so if they are not isolated their X floods the scan compactor (or the LBIST signature register) and destroys coverage, exactly as an un-bypassed memory does; the fix is to isolate them by driving their digital-facing interfaces to known values in test mode (and to safe-state a block's outputs so it can't cause contention or disturb neighbors), using test-mode isolation muxes/gates from the mode decoder — and for SoC cores, a core test wrapper (IEEE 1500) isolates each core for independent test — so a coverage loss concentrated near a non-scan/analog interface is an isolation (X-injection) problem, not hard-to-test digital logic. (X-sources at the compactor are 7.4/7.5; at the MISR are 9.4; the memory bypass is 8.6; the mode decoder is 11.2.)
9. Common Mistakes
- Not isolating non-scan/analog/IP/memory. They inject X into the compactor/MISR (7.4/9.4) — drive interfaces known.
- Blaming digital logic for X-masking near an IP. It's the IP injecting X — isolate it.
- Leaving a block's outputs live in test. Safe-state them → no contention/damage/disturbing neighbors.
- Skipping core wrappers. For independent per-core test, wrap cores (IEEE 1500).
- Ad-hoc isolation. Route isolation from the mode decoder (11.2) — coherent with the mode.
10. Industry Best Practices
- Isolate all non-scan/analog/IP/memory interfaces in test (drive known values) — no X-injection.
- Safe-state block outputs in test — prevent contention/damage/disturbing neighbors.
- Use core test wrappers (IEEE 1500) for independent, isolated per-core test.
- Route isolation from the mode decoder (11.2) — coherent, mutually exclusive with the mode.
- Check the masking report — coverage loss near an interface is an X-injection/isolation issue.
11. Senior Engineer Thinking
- Beginner: "Coverage is low near the analog block — the digital logic there is hard to test."
- Senior: "The analog block can't be scanned — it's injecting X onto its digital outputs → flooding the compactor → masking → coverage loss (same as an un-bypassed memory, 7.5). I isolate it — drive its digital interface to known values in test — and coverage recovers. I safe-state its shared-bus drivers too, and for cores I use an IEEE 1500 wrapper for independent test. Isolation, not 'hard logic.'"
The senior reads coverage loss near a non-scan/analog interface as an X-injection/isolation problem and isolates the block.
12. Silicon Impact
Isolation is the discipline that lets a heterogeneous, multi-block SoC be tested cleanly, block by block — and it solves two failure modes that would otherwise cripple the test. The first is X-injection: any block that can't be scan-tested — analog, non-scan IP, memory — produces unknown (X) during a scan test, and unisolated, that X floods the scan compactor (7.4/7.5) or corrupts the LBIST signature (9.4), destroying coverage — the exact same mechanism as an un-bypassed memory (8.6), which is why a coverage loss concentrated near a non-scan/analog interface is an isolation problem, not hard-to-test digital logic (the story). The fix — drive the block's digital-facing interface to known values in test — is a generalization of the memory bypass, and it recovers the coverage the un-isolated block was stealing. The second failure mode is cross-block disturbance and device protection: a block's scan-driven outputs are arbitrary, so unmanaged they can contend on shared buses, disturb a neighbor's test, or even damage the device — so you safe-state them. The third capability isolation provides is independent, isolated per-core test via core test wrappers (IEEE 1500) — the core-level cousin of the 1149.1 boundary scan (Chapter 10) — which is essential for large SoCs built from reusable cores that must be tested (and their tests kept apart) independently. The common mechanism — test-mode isolation muxes/gates from the mode decoder (11.2) — ties isolation into the mode organization of this chapter. For the DFT engineer, isolation is what keeps scan/BIST coverage clean and cores independently testable; for the analog/IP/RTL engineer, making their block's interface isolatable and outputs safe-stated is an integration obligation; and for the whole SoC, isolation is what prevents blocks from corrupting each other's tests — the property the clock-gated example (11.5) exercises and that Chapter 12 must account for in DFT timing/constraints.
13. Engineering Checklist
- Isolated all non-scan/analog/IP/memory interfaces (drive known values in test) — no X-injection (7.4/9.4).
- Safe-stated block outputs (disable/known) — no contention/damage/disturbing neighbors.
- Used core test wrappers (IEEE 1500) for independent, isolated per-core test.
- Routed isolation controls from the mode decoder (11.2) — coherent with the mode.
- Confirmed coverage loss near interfaces is resolved by isolation (not chased as hard logic).
14. Try Yourself
- Show a non-scan/analog block injecting X into the scan compactor (7.4) — and isolate it (drive interface known).
- Safe-state a block's shared-bus outputs in test — explain preventing contention/damage.
- Wrap a core with a wrapper (IEEE 1500) — explain independent, isolated per-core test.
- Relate this to the memory bypass (8.6) — same idea, generalized to analog/IP.
- Given X-masking near an IP interface, diagnose it as X-injection/isolation, not hard logic.
The concepts are tool-neutral; IEEE 1500 is a core-test-wrapper standard. No paid tool required to reason about isolation.
15. Interview Perspective
- Weak: "You isolate blocks so they don't interfere in test."
- Good: "Drive non-scan/analog interfaces to known values so they don't inject X, and safe-state outputs to avoid contention."
- Senior: "Isolation does three jobs. (1) Stop X-injection: analog/non-scan IP/memory can't be scanned and output X in test — unisolated, that X floods the scan compactor (7.4) or corrupts the MISR (9.4), so I drive their digital interfaces to known values in test (the memory bypass of 8.6, generalized). (2) Don't disturb neighbors / protect the chip: a block's scan-driven outputs are arbitrary, so I safe-state them (disable/known) to avoid contention, disturbing a neighbor's test, or damage. (3) Independent per-core test: I wrap cores with wrapper boundary cells — IEEE 1500, the core-level cousin of 1149.1 — for isolated, independent test. The mechanism is test-mode isolation muxes/gates from the mode decoder (11.2). So coverage loss near a non-scan/analog interface is an isolation (X-injection) problem, not hard logic."
16. Interview / Review Questions
17. Key Takeaways
- Putting a block in test often requires isolating it from the rest of the chip — or the rest from it — for three reasons, all controlled by test-mode isolation muxes/gates from the mode decoder (11.2).
- Stop X-injection: analog, non-scan IP, and memory blocks can't be scan-tested and output X — unisolated, that X floods the scan compactor (7.4) or corrupts the LBIST MISR (9.4), destroying coverage; isolate by driving their digital-facing interfaces to known values in test (the memory bypass of 8.6, generalized).
- Don't disturb neighbors / protect the chip: a block's scan-driven outputs are arbitrary → safe-state them (drive known / disable drivers) to avoid contention, disturbing a neighbor's test, or damage.
- Independent per-core test: core test wrappers (IEEE 1500) — wrapper boundary cells around a core, the core-level cousin of 1149.1 — enable isolated, independent per-core test in a large SoC.
- A coverage loss concentrated near a non-scan/analog interface is an isolation (X-injection) problem, not hard-to-test digital logic — isolate the block and the coverage it was stealing comes back. Next: 11.5 — a worked example: test control of a clock-gated block.
18. Quick Revision
Isolating functional logic in test. Three jobs (all via test-mode isolation muxes/gates from the mode decoder, 11.2): (1) Stop X-injection — non-scan/analog/IP/MEMORY can't be scanned → output X → unisolated floods the scan compactor (7.4) / corrupts the LBIST MISR (9.4) → DRIVE their digital interfaces to KNOWN values in test (the memory bypass 8.6, generalized). (2) Don't disturb neighbors / protect the chip — a block's scan-driven outputs are arbitrary → SAFE-STATE them (drive known / disable drivers) → no contention/damage. (3) Independent per-core test — core wrappers (IEEE 1500) = boundary scan AROUND a core → isolated, independent test. Coverage loss near a non-scan/analog interface = an ISOLATION (X-injection) problem, NOT hard logic → isolate → coverage recovers. Next: 11.5 — test control of a clock-gated block.