What does physical implementation and signoff look like for a multivoltage design (secondary PG placement constraints, check_mv_design, Early Data Check policies)?

Short Answer

You load the UPF, insert and check the power-management cells, build voltage areas, switches and secondary PG, then place, clock and route with the MV rules on, and re-run check_mv_design (ICC2) after every step. Signoff closes timing in PrimeTime against the same UPF and checks wake-up current and IR drop in RedHawk. The Early Data Check Manager decides which data problems stop the flow and which the tool tolerates or repairs.

Technical Explanation

• Load and insert: load_upf (ICC2), then optionally create_mv_cells (ICC2), which inserts level shifters, isolation and repeaters and runs commit_upf (ICC2).
• Check early: check_mv_design (ICC2) checks power intent and PG connectivity; run it after insertion, placement, CTS, routing and every ECO.
• Floorplan: create_voltage_area (ICC2) per domain, switch arrays and AO channels, then secondary PG constraints so dual-rail cells sit near their straps.
• Data checks: set_early_data_check_policy (ICC2) sets strict, lenient or normal globally, or error, tolerate or repair per check.
• Policy trap: you cannot move a check to a stricter policy without reset_upf (ICC2); the one exception is mv.va.missing_voltage_area (ICC2).
• Signoff: PrimeTime reads the UPF for voltage-aware timing, RedHawk runs ramp-up and dynamic IR, and save_upf (ICC2) writes the hand-off UPF.

# [ICC2]  icc2_shell
load_upf mychip.upf
create_mv_cells
check_mv_design
create_voltage_area -power_domains {PD_CPU} -region {{100 100} {400 300}} -guard_band {{5 5}}
derive_secondary_pg_placement_constraints
check_secondary_pg_placement_constraints
set_early_data_check_policy -policy strict
report_early_data_checks
save_upf mychip_impl.upf
# [PrimeTime]  pt_shell
load_upf mychip.upf
report_supply_net
# [RedHawk]  redhawk TCL shell
perform analysis -lowpower

What To Check

• check_mv_design is clean after every flow step, not just at the end.
• Every switchable domain has a voltage area, switch array and AO channel.
• Secondary PG constraints pass check_secondary_pg_placement_constraints.
• PT and RedHawk read the same UPF that ICC2 implemented.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): check_mv_design reports zero errors after routing and report_early_data_checks shows no repaired checks.
• Suspicious (illustrative): Checks set to repair fixed 30 items silently, and nobody reviewed what changed.
• Hard stop: check_mv_design shows missing isolation after the last ECO, or PT reads a different UPF than ICC2 wrote.

What The Interviewer Is Testing

• Can you order the MV flow steps and say which tool owns each?
• Do you re-check MV rules after every netlist change?
• Do you know how Early Data Check policies affect the flow?

Follow-up Question & Model Response

"Why would you run with a lenient data-check policy early and strict later?"

Candidate Model Response: Early on the UPF and libraries are incomplete, so strict checks would stop you on known gaps. A lenient or per-check tolerate policy lets you explore the floorplan and get QoR feedback. Before signoff you want every data problem to be an error, not a silent repair. Because tightening a check needs reset_upf (ICC2), plan the policy switch at a point where reloading the UPF is cheap.