A chip that cannot be told cleanly whether it is running or being tested tests neither well. Scan wants clocks toggling with block outputs isolated, then the real logic reconnected for the capture pulse; memory test wants the SRAM wrappers in test while the logic around them holds still; mission wants all of it gone without a trace. Without named modes and one owner for switching between them, each block's test hooks point in different directions and the first tester program becomes archaeology. The remedy is a short list of modes and a single owner.
The NanoSoC test extension defines three chip modes in its test controller. Mission mode disconnects every test mux, enables the functional clocks and resets, and arms the test-entry detector. Scan-test mode has two phases steered by the scan-enable signal: with scan enable high the chains shift on the tester's clock with block outputs isolated through wrapper cells and the switchable-domain crossings clamped, so shift activity cannot leak into the always-on controller; with scan enable low one or two capture pulses reach the flops with isolation released inside the partition under test. Memory-test mode hands the two SRAM macros and the ROM interface to the tester through their wrappers while the surrounding logic is held in reset, so memory results cannot be corrupted by logic toggling. Shift and capture are phases of one mode, not separate chip modes.
Where the capture clock comes from depends on the fault model. Stuck-at patterns can capture on a slow clock, because they test logic function. Delay-fault patterns need capture pulses at functional speed, taken from the PLL through an on-chip clock controller that emits the launch and capture pulses, and without them a timing path is never exercised. Shift uses the tester's clock and does not need the PLL at all; entry into a mode whose capture clocks come from the PLL is refused until PLL lock is seen. One controller owns every transition, sequenced so clocks are stable before release and isolation precedes any power move, reusing the reset and power ordering of the earlier parts of the course.
# not-run: NanoSoC test-mode table for the test extension, illustrative
mission: test muxes off, functional clocks and resets, entry detector armed
scan test: scan enable high = shift on the tester clock, wrappers isolating, crossings clamped
scan enable low = capture pulse(s): slow for stuck-at, PLL-derived at speed for delay faults
memtest: SRAM0, SRAM1 and ROM wrappers to tester, surrounding logic held in reset
owner: one test controller in PD_AON; transitions sequenced with clocks, resets and isolationThe mode table above, current, with every mux, clock source and isolation state per mode and per phase, including the scan-enable value.
One owner for transitions; no block switches its own test hooks independently of the controller.
Capture defined with real clocks (slow for stuck-at, PLL-derived at speed for delay faults) and scan reset as an ordinary synchronised release, never produced by gating a scan clock.
Simulate every mode transition in both directions, including the illegal ones the controller must refuse: at-speed capture requested while the PLL is unlocked, capture with isolation still clamped, memory test while the CPU fetches. Each refusal must be a clean stay-in-mode, never a half-switched fabric. When a tester program misbehaves, read back the mode register first; most DFT debug sessions end at a chip in the wrong mode.
A stuck-at fault changes logic function, so any capture clock finds it. A delay fault only shows when a path is asked to finish within its real period, so the capture pulses must come at functional speed from the PLL through the on-chip clock controller. Shift stays on the slow tester clock because it only moves data.