What is the golden UPF flow, and why use it instead of save_upf at every step?

Short Answer

In the golden UPF flow you never rewrite the RTL power intent: every tool reads the original file plus supplemental UPF files that hold only tool-made changes. You enable it with mv.upf.enable_golden_upf (ICC2) before loading the UPF and write changes with save_upf -format supplemental (ICC2), so reviewers, PT and VC LP all check the same intent.

Technical Explanation

• UPF-prime flow: each tool writes a full UPF' or UPF'' that mixes original commands with its own changes, losing comments, wildcards and structure.
• Golden flow: the original file stays unchanged; synthesis and ICC2 each write a supplemental UPF with only power-intent changes.
• Enable before load: set mv.upf.enable_golden_upf (ICC2) to true first, then read supplementals with load_upf -supplemental (ICC2).
• Tool-specific branches: conditional statements for one tool survive in the golden file; the UPF-prime flow drops them.
• PrimeTime: set_app_var enable_golden_upf true (PT) turns it on; after that, UPF commands other than queries run only through load_upf (PT) scripts.
• Name mapping: optimization and ungrouping rename objects, so golden names may not match the netlist; a name-mapping file bridges them.
• What breaks: hand-editing the golden file mid-flow, or giving PT an older supplemental than VC LP, lets tools check different intent without any error.

# [ICC2]  icc2_shell
set_app_options -as_user_default -list {mv.upf.enable_golden_upf true}
load_upf mychip.upf -supplemental dc_supp.upf
save_upf -format supplemental icc2_supp.upf
# [PrimeTime]  pt_shell
set_app_var enable_golden_upf true
# [VC LP]  vc_static_shell
read_upf mychip.upf -supplemental icc2_supp.upf -strict_check false
check_lp -stage design

What To Check

• The golden file is unchanged from RTL power-intent signoff to tapeout.
• Every downstream tool reads the same golden file and the same supplementals, in the same order.
• The golden option is set in ICC2 before the first load_upf.
• Supplementals hold tool changes such as inserted cells and updated elements, not rewritten strategies.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): mychip.upf is byte-identical to the RTL release and icc2_supp.upf holds 9 lines of tool-derived updates.
• Suspicious (illustrative): icc2_supp.upf redefines a whole set_isolation strategy instead of refining it, so someone changed intent inside the implementation tool.
• Hard stop: PT and VC LP read different supplemental versions, or ICC2 loaded the UPF before the golden option was set.

What The Interviewer Is Testing

• Can you explain what a supplemental UPF holds and why the golden file never changes?
• Do you keep every signoff tool on the same power intent?

Follow-up Question & Model Response

"IEEE 1801 also uses the words "golden UPF". Is that the same thing?"

Candidate Model Response: Not exactly. The standard's successive-refinement section calls the configuration UPF, where strategies are added to the IP constraints, "sometimes the golden UPF". The Synopsys golden UPF flow is a file-handling method: keep one original file and carry tool changes in supplementals. Both point the same way, because the intent you reviewed stays the file every tool reads.