How do you confirm every crossing that needs isolation actually has it?

Short Answer

Check functional and DFT crossings separately. For functional paths, run check_mv_design -isolation (ICC2), which checks isolation strategies, isolation cells and the isolation of the netlist, then trace anything it flags with report_mv_path (ICC2) to see which strategy applies and why a cell is missing or unassociated. Scan stitching adds crossings the RTL UPF never listed, so after scan insertion run check_isolation_coverage -dft_signals (ICC2), which reports DFT paths with an isolation violation that no strategy covers.

Technical Explanation

• Coverage is not existence: a strategy on PD_COP proves nothing by itself; its element list or source/sink filters can miss the one port that crosses.
• Functional check: check_mv_design -isolation (ICC2) restricts the full MV check to isolation strategy and isolation cell rules; run it after create_mv_cells (ICC2).
• Tracing: report_mv_path -net (ICC2) shows strategy applicability and association on one path; -all_not_associated lists every isolation or LS cell no strategy owns.
• DFT scope: check_isolation_coverage (ICC2) requires -dft_signals and analyzes only paths through scan, test-mode and wrapper signal pins, never plain functional ports.
• DFT options: -from filters driver domains, -to load domains, -clamp_value 0|1|latch|all limits which strategies count, and -ignore_unimplemented_strategies counts only implemented ones.
• Default coverage: a strategy still waiting to be implemented counts as coverage, and so does one whose isolation supply cannot drive the loads.
• What breaks: an uncovered PD_COP output floats when VDD1p0_SW drops, so the always-on load sees an unknown value and can draw crowbar current.

# [ICC2]  icc2_shell
create_mv_cells
check_mv_design -isolation
report_mv_path -net U_COP/irq_out
report_mv_path -all_not_associated
check_isolation_coverage -dft_signals -from PD_COP -to {PD_MYCHIP PD_CPU}
check_isolation_coverage -dft_signals -ignore_unimplemented_strategies

What To Check

• Every PD_COP output that reaches an on domain has an isolation cell owned by a strategy.
• The clamp value of each covering strategy suits its load while PD_COP is off.
• report_mv_path -all_not_associated (ICC2) returns no isolation cells.
• Scan crossings added by stitching are clean under check_isolation_coverage -dft_signals (ICC2).

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): check_mv_design -isolation (ICC2) is clean on all 64 PD_COP outputs, and the DFT coverage run after scan insertion reports no violating paths.
• Suspicious (illustrative): Functional checks are clean, but -ignore_unimplemented_strategies shows two scan crossings: a DFT strategy never turned into cells.
• Hard stop: U_COP/irq_out to PD_CPU has no strategy and no isolation cell: U_CPU sees a floating input every time PD_COP powers down.

What The Interviewer Is Testing

• Do you separate strategy defined, crossing covered and cell implemented?
• Do you know which check covers functional crossings and which covers DFT paths?

Follow-up Question & Model Response

"Why can coverage look clean before scan insertion and fail after it?"

Candidate Model Response: Scan stitching punches new ports between domains that the RTL UPF never listed. A scan_out from PD_COP into a PD_MYCHIP chain is a new crossing no element-based strategy mentions. check_isolation_coverage -dft_signals (ICC2) finds those paths and suggests set_dft_isolation (ICC2) strategies. You either add strategies and rerun insert_dft (ICC2), or add them incrementally and apply them with commit_dft_isolation (ICC2).