What changes for scan and DFT when the design has power domains?

Short Answer

Scan stitching adds paths the functional UPF never saw: a chain that runs from PD_COP into PD_MYCHIP crosses a domain boundary and needs isolation and level shifting like any data signal. ICC2 covers these with set_dft_isolation (ICC2), which reuses an existing isolation strategy for DFT connections, or with a placeholder strategy that generate_mv_constraints -dft_isolation (ICC2) fills after insert_dft (ICC2). check_isolation_coverage -dft_signals (ICC2) then shows what is still uncovered.

Technical Explanation

• New crossings: stitching punches ports between domains for scan in, scan out, scan enable, test mode and scan clock signals.
• set_dft_isolation: needs -ref_strategy and -ref_domain; -dft_target_domain, -dft_source_domain and -type narrow which DFT connections it covers.
• First wins: if the command repeats for the same target domain and connection type, only the first one is honoured.
• Placeholder flow: write a source/sink strategy with an empty element list in the RTL UPF; the generate command fills it with DFT crossings only.
• Why a placeholder: a plain source/sink strategy aimed at scan also hits functional paths and inserts redundant isolation cells.
• Level shifters: the same idea exists for shifters with generate_mv_constraints -dft_level_shifter (ICC2).
• What breaks: an unisolated scan_out from an off PD_COP floats into the always-on chain, so the chain shifts X in any test mode with PD_COP off.

# [UPF]  design.upf
set_isolation ISO_DFT -domain PD_COP -source SS_COP -sink SS_AON -elements {} -isolation_supply SS_AON -clamp_value 0 -isolation_signal U_PC/ISE -isolation_sense high
# [ICC2]  icc2_shell
insert_dft
generate_mv_constraints -dft_isolation -apply -output dft_iso.upf
# alternative: reuse an existing strategy for one connection type
set_dft_isolation -ref_strategy ISO_COP_OUT -ref_domain PD_COP -dft_target_domain PD_MYCHIP -type scan_out
commit_dft_isolation
check_isolation_coverage -dft_signals
create_mv_cells

What To Check

• Every DFT connection that crosses a boundary shows as covered under -dft_signals.
• The placeholder strategy now lists only DFT pins, no functional ports.
• No repeated set_dft_isolation (ICC2) for the same target domain and type.
• Scan hops from 0.9 V PD_CPU into 1.0 V domains carry level shifters.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): No violating DFT paths remain; PD_COP scan_out is clamped to 0 in every test mode where PD_COP is off.
• Suspicious (illustrative): Functional PD_COP outputs now carry two isolation cells each: a broad source/sink strategy meant for scan caught them too.
• Hard stop: The PD_COP scan_out into the PD_MYCHIP chain has no isolation: the chain shifts X whenever PD_COP is off.

What The Interviewer Is Testing

• Do you know that stitching creates crossings after the UPF is written?
• Can you explain why the placeholder flow avoids redundant isolation?

Follow-up Question & Model Response

"Should scan chains cross power domains at all?"

Candidate Model Response: Where you can, keep each chain inside one domain, so a powered-down block does not break chains that stay on. When that costs too many scan ports or unbalanced chains, crossings are accepted and protected like any data path. Test modes that power a domain down must then bypass its segment or rely on the clamp. That partitioning is a DFT and floorplan decision made before the MV strategies are written.