Walk through the "smart-derive isolation strategy" gotcha for newly punched control ports: what goes wrong and how is it fixed?

Short Answer

When ICC2 punches new hierarchical ports for retention, switch or isolation control nets, it derives a -no_isolation strategy on them so existing strategies do not grab them. If the control driver can be off while the port receiver is on, that becomes an isolation violation you cannot fix with your own strategies. Setting mv.cells.smart_derive_iso_strategy_on_new_control_ports (ICC2) to true makes the tool check the PST first and derive -no_isolation only where there is no violation.

Technical Explanation

• Default: new punched ports on save/restore, switch control and isolation control nets get a derived -no_isolation (UPF).
• Why: it keeps an existing isolation strategy from clamping a control net that must pass straight through.
• Gotcha: if the control driver is less always-on than the punched port, the derived strategy blocks any isolation you add.
• Fix: set mv.cells.smart_derive_iso_strategy_on_new_control_ports (ICC2) to true, and the tool checks the control path against the PST first.
• No violation: it still derives -no_isolation. A violation: your strategy applies and an isolation cell goes in.
• The ICC2 MV UG says this currently covers only new punched pins on the retention control path.
• What breaks without it: a save pin fed from a domain that can be off floats, and the retention flops save unknown data.

# [ICC2]  icc2_shell
set_app_options -list {mv.cells.smart_derive_iso_strategy_on_new_control_ports true}
# [UPF]  design.upf
create_supply_set SS_AON -function {power VDD_AON} -function {ground VSS}
set_retention RET_PDC -domain PDC -elements {C/ret1 C/ret2} -retention_supply SS_AON -save_signal {save high} -restore_signal {restore high}
set_isolation ISO1 -domain PDC -applies_to inputs -diff_supply_only TRUE -isolation_supply PDC.primary -isolation_signal iso1 -isolation_sense low -location self -clamp_value 0
# [ICC2]  icc2_shell
check_mv_design

What To Check

• List every port punched for save, restore, switch and isolation control after compile.
• For each one, compare driver and receiver supplies across all PST states.
• The option is set before the step that punches the ports.
• Every violating control port now has an isolation cell, and the others have none.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): After compile C/save has an ISO1 cell, and check_mv_design (ICC2) reports no isolation violation on the save path.
• Suspicious (illustrative): C/save still carries a derived -no_isolation (UPF) and check_mv_design (ICC2) keeps reporting it.
• Hard stop: The PDC save input floats whenever VDDT is off, so the retention flops capture unknown data.

What The Interviewer Is Testing

• Whether you know tools create ports and strategies you never wrote.
• Whether you tie a violation to the PST state that causes it.

Follow-up Question & Model Response

"Why does the tool derive -no_isolation on punched control ports at all?"

Candidate Model Response: Control nets such as save and isolation enable often enter a domain whose isolation strategy covers all its inputs. Without the derived -no_isolation, that strategy would clamp the very signal that controls the domain. The default protects the common case, where the driver is at least as on as the receiver. The smart option drops it only where the PST shows the driver can be off.