ExpertQuestion 46 of 50Source: Synopsys IC Compiler II Multivoltage User Guide: Isolation Cells and Heterogeneous Loads, Isolation Cell Insertion on Nets Driven By Constants, Order of Precedence of Isolation Strategies

How are nets with loads in several domains, or nets driven by constants, isolated?

From PDVerse Low-Power Physical Design Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

When one driver fans out to loads on different supplies, a port-based strategy cannot say which branch needs isolation, so you describe it by supplies: -source, -sink and -diff_supply_only on set_isolation (UPF) put cells only on branches whose load supply differs from the driver. Nets driven by literal constants count as real drivers with a related supply, and ICC2 can skip isolation where the constant already equals the clamp value.

Schematic: driver U_COP/done in hatched PD_COP (VDD1p0_SW) fans out to a counter in PD_COP, an interrupt controller in PD_MYCHIP (VDD1p0) and a status flop in PD_CPU (VDD0p9); AND-type clamp-0 isolation cells sit only on the PD_MYCHIP and PD_CPU branches (-diff_supply_only true, -location fanout); a second net tied to 1'b0 feeds a hard macro with no isolation cell. — Technical Reference DiagramHow are nets with loads in several domains, or nets driven by constants, isolated?

Technical Explanation

Heterogeneous fanout: a PD_COP output drives loads in PD_COP, PD_MYCHIP and PD_CPU; only the branches into always-on domains need a clamp.
Supply filters: -source and -sink match driver and load supply sets; -diff_supply_only true isolates only where the two differ.
Location fanout: puts a cell at each qualifying load; the ICC2 MV UG allows it only with a -source, -sink or -diff_supply_only filter.
Precedence: explicit -elements, instance and domain-name strategies all outrank -source/-sink ones, which outrank diff_supply_only true, which outranks false.
Literal constants: a 1'b0 or 1'b1 is a valid driver; its related supply comes from set_port_attributes -literal_supply, otherwise the primary of the domain it sits in.
Skipping needless cells: with relax_constant_corruption_for_macro_inputs_and_primary_outputs true, a constant that equals the clamp value into a macro input or primary output gets no cell.
Legacy form (still accepted by ICC2/PT): set_isolation_control (UPF) carries the isolation signal and sense separately; the legacy -isolation_power_net is not allowed with -location fanout.

# [UPF]  mychip.upf
set_isolation ISO_COP_DIFF -domain PD_COP -applies_to outputs -diff_supply_only true -clamp_value 0 -isolation_signal ise -isolation_sense high -location fanout
# [ICC2]  icc2_shell
set_design_attributes -attribute relax_constant_corruption_for_macro_inputs_and_primary_outputs true
create_mv_cells
check_mv_design -isolation
report_mv_path -all_heterogeneous_paths

What To Check

For each crossing net, the driver supply and every load supply.
Isolation lands only on branches whose load supply differs from the driver.
Constant-driven nets that cross a boundary have a known related supply.
No older domain-wide strategy still covers the same ports.

Command Checks & Actions

UPF (design.upf)

set_isolation ISO_COP_DIFF -domain PD_COP -applies_to outputs -diff_supply_only true -clamp_value 0 -isolation_signal ise -isolation_sense high -location fanout

Isolate only branches whose load supply differs, placing cells at the loads

ICC2 (icc2_shell)set_design_attributes -attribute relax_constant_corruption_for_macro_inputs_and_primary_outputs true

Skip isolation on constants that already equal the clamp value

ICC2 (icc2_shell)create_mv_cells

Insert the isolation cells the strategies call for

ICC2 (icc2_shell)check_mv_design -isolation

Check isolation strategies and cells after insertion

ICC2 (icc2_shell)report_mv_path -cell U_COP/done_iso

Show the strategy, supply and loads of one inserted cell

Healthy, Suspicious & Hard-stop Results

Healthy (illustrative): U_COP/done drives 3 loads and gets exactly 2 isolation cells, on the PD_MYCHIP and PD_CPU branches.
Suspicious (illustrative): The PD_COP counter branch also has a cell, so an older domain-wide strategy is still winning somewhere.
Hard stop: check_mv_design -isolation reports an unprotected branch into PD_MYCHIP.

Common Mistake

The Trap: Keeping an old domain-wide ISO_COP strategy with -applies_to outputs next to the new supply-based one.

Strategies implied by the domain name outrank -source, -sink and -diff_supply_only strategies in the ICC2 order, so the old one still isolates every branch, internal loads included.

What The Interviewer Is Testing

Can you isolate by supply relationship instead of by port list?
Do you know where supply-based strategies sit in the precedence order?

Follow-up Question & Model Response

"Why does -location fanout need a source, sink or diff_supply_only filter?"

Candidate Model Response: Fanout places a cell at each load instead of once at the domain boundary, so the tool must decide per branch which loads need one. The supply filters give that per-branch answer; without them every load would look the same. The ICC2 MV UG also bars -isolation_power_net with fanout, while parent and self locations accept it. If you mix -elements with a supply filter, you must set the derived_iso_strategy attribute first, and fanout is then the only legal location.

Practical Example

Design Scenario: (illustrative) U_COP/done in PD_COP (VDD1p0_SW) drives a counter in PD_COP, the interrupt controller in PD_MYCHIP (VDD1p0) and a status flop in PD_CPU (VDD0p9). A domain-wide output strategy would place one cell at the PD_COP boundary and slow the internal counter path too. ISO_COP_DIFF with -diff_supply_only true and -location fanout places 2 clamp-0 cells, one before each always-on load, and leaves the counter path alone. A second net, U_COP/mode, is tied to 1'b0 in RTL and feeds a hard macro in PD_MYCHIP; with the relax attribute set and the clamp at 0, it gets no cell.

Low-Power & UPF Handbook