How is hierarchical UPF constructed for nested power domains, and what does create_composite_domain do?

Short Answer

Each block carries its own UPF, and the top UPF loads it into the block instance with load_upf -scope (UPF), then drives the block supply ports from top nets. Top-down, ICC2 cuts the chip intent into block UPFs with split_constraints (ICC2); bottom-up, finished blocks come back as ETMs or macros whose port supplies you describe from outside. create_composite_domain -subdomains (UPF) only groups existing domains into one container, and a strategy written on it applies to each subdomain; tool support varies by release.

Technical Explanation

• Block UPF: written at the block scope; it creates the block domains, switches and strategies, and exposes supply ports for the parent to drive.
• Top UPF: creates the top domains, loads each block with load_upf -scope (UPF) and ties nets to block ports with connect_supply_net (UPF).
• Top-down: split_constraints (ICC2) writes block UPFs from the chip intent. By default every top-scope supply is visible inside each block.
• Set mv.hierarchical.split_constraints_include_only_existing_supplies_in_block (ICC2) to true when your methodology needs self-contained block UPF.
• Bottom-up: a finished block returns as an ETM or macro. ICC2 then takes port supplies from set_port_attributes -receiver_supply (UPF) or set_related_supply_net (UPF), top scope first.
• save_upf -full_chip (ICC2) writes one UPF from the top through every block; -block limits it to the blocks you list.
• What breaks: saved UPF holds no constraints for ETMs, macros or empty modules, so the top must keep their port attributes itself.

# [UPF]  cop_blk.upf (scope U_COP)
create_power_domain PD_COP -elements {.}
create_supply_port VDD1p0 -direction in
create_power_switch COP_SW -domain PD_COP -input_supply_port {in VDD1p0} -output_supply_port {out VDD1p0_SW} -control_port {ctrl PSE} -on_state {ON in {ctrl}}
# [UPF]  mychip.upf
create_power_domain PD_MYCHIP -elements {.}
load_upf cop_blk.upf -scope U_COP
connect_supply_net VDD1p0 -ports {U_COP/VDD1p0}
set_port_attributes -ports {U_ETM/wake} -receiver_supply SS_AON
# [ICC2]  icc2_shell
save_upf -full_chip -block {COP} mychip_full.upf

What To Check

• The block UPF loads at its instance with load_upf -scope (UPF) and every block supply port is connected at the top.
• Top and block agree on voltages and power states for shared supplies.
• Every ETM and macro input has a receiver supply stated at the top scope.
• The full-chip UPF reloads and passes check_mv_design (ICC2).

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Block and top UPF load with no supply errors and check_mv_design (ICC2) shows no unconnected block supply ports.
• Suspicious (illustrative): An ETM input falls back to the domain primary supply because no receiver supply was given at either scope.
• Hard stop: A block supply port has no driver at the top: the block domain is unpowered in the intent, so stop and connect it.

What The Interviewer Is Testing

• Whether you know how block and top UPF connect: scope, supply ports and connected nets.
• Whether you can choose top-down or bottom-up and say what ICC2 needs for an ETM.

Follow-up Question & Model Response

"How does ICC2 decide the receiver supply of an ETM input with no related-pin data?"

Candidate Model Response: It walks a fixed priority list. A set_port_attributes -receiver_supply at the top scope wins, then set_related_supply_net at the top scope, then the same two at the block scope. If none exist it falls back to the power domain primary supply. That fallback is often wrong for an always-on input, so state the supply.