Scan paths are failing isolation checks across domains. How do you resolve them?

Short Answer

DFT insertion creates new ports and nets that cross power domains, and the functional isolation strategies often do not cover them. Run check_isolation_coverage -dft_signals (ICC2) to list the violating scan paths with suggested strategies, then fix them one of two ways: add strategies and rerun insert_dft (ICC2), or add incremental set_dft_isolation (ICC2) rules and apply them with commit_dft_isolation (ICC2).

Technical Explanation

• Source of the problem: insert_dft (ICC2) and optimize_dft punch new ports and nets, so scan_in, scan_out and scan_enable paths cross domain boundaries.
• Coverage report: check_isolation_coverage -dft_signals (ICC2) lists violating DFT paths, supply availability, existing strategies and suggested set_dft_isolation (ICC2) commands.
• Reuse a strategy: set_dft_isolation (ICC2) must name an existing strategy with -ref_strategy and -ref_domain, filtered by target domain, sink supply or -type.
• Path 1: add the needed strategies and rerun insert_dft (ICC2), so new ports are isolated as they are created.
• Path 2: add incremental set_dft_isolation (ICC2) rules after DFT, then commit_dft_isolation (ICC2) applies them to the affected DFT signals.
• Automation: generate_upf_strategies (ICC2) appends new DFT ports to matching element-based strategies; generate_mv_constraints -dft_isolation (ICC2) fills placeholder source/sink strategies.
• What breaks: a broad source/sink strategy aimed at scan also matches functional crossings, adding redundant isolation cells and delay.

# [ICC2]  icc2_shell
check_isolation_coverage -dft_signals -from PD_COP -to PD_MYCHIP
set_dft_isolation -ref_strategy ISO_COP_OUT -ref_domain PD_COP -dft_target_domain PD_MYCHIP -type scan_out
set_dft_isolation -ref_strategy ISO_COP_OUT -ref_domain PD_COP -dft_target_domain PD_MYCHIP -type scan_enable
commit_dft_isolation
report_dft_isolation
check_isolation_coverage -dft_signals

What To Check

• Every DFT signal type leaving a switchable domain: scan_in, scan_out, scan_enable, test_mode and scan_clock.
• Each violating path gets one strategy, on the source or the sink side, not both.
• The referenced strategy clamps to the value the DFT signal must hold in functional mode, such as 0 for scan_enable.
• Strategies aimed at DFT paths do not also land on functional paths.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): check_isolation_coverage -dft_signals reports 0 violating DFT paths after the fix.
• Suspicious (illustrative): Coverage is clean, but PD_COP-to-PD_MYCHIP scan_out paths are isolated in both domains, so redundant cells were inserted.
• Hard stop: A scan_enable path from PD_COP into PD_MYCHIP still violates and the report shows no available isolation supply.

What The Interviewer Is Testing

• Do you know that DFT insertion creates crossings the functional UPF never saw?
• Can you choose between rerunning insert_dft and incremental DFT isolation, and avoid redundant cells?

Follow-up Question & Model Response

"When would you pick generate_upf_strategies over set_dft_isolation?"

Candidate Model Response: set_dft_isolation needs an existing strategy for each crossing, and you decide source or sink yourself, which gets hard with many domains. generate_upf_strategies runs after insert_dft and appends the new DFT ports to existing element-based strategies whose driver and load supplies match. It picks one strategy per path, so the same path is not isolated twice. For paths no existing strategy covers, you describe new ones with define_upf_isolation_rule before running it.