What is "power intent," and why do we need a separate language (UPF) to describe it?
From PDVerse Low-Power Physical Design Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
Power intent is the description of how a chip is powered: which logic sits on which supply, which blocks can switch off, and what each domain boundary needs to stay safe. It lives in a separate UPF (IEEE 1801) file because RTL describes function, not supplies, and one file read by synthesis, P&R, timing and simulation keeps every tool working from the same power plan.
Technical Explanation
- Power intent covers power domains, supply nets, power states and the isolation, level-shifter, retention and power-switch strategies. RTL has no syntax for any of it.
- A separate file lets you change the power plan without touching verified RTL, and reuse the same RTL on a chip with a different plan.
- One UPF file travels the flow: synthesis reads it, ICC2 reads it with
load_upf(ICC2), PrimeTime withload_upf(PT), and power-aware simulation uses it too. - The tools act on it.
create_mv_cells(ICC2) inserts the cells the strategies ask for, andcheck_mv_design(ICC2) checks the netlist against it. - A power domain is a UPF object, not a netlist object. You will not find it by reading gates; tools learn it only from the UPF.
- Each step writes updated intent with
save_upf(ICC2): a UPF-prime file in the traditional flow, or a supplemental file beside the untouched golden UPF. - If two tools read different UPF versions, simulation checks one power plan while silicon implements another, and bugs like a missing isolation cell slip through.
Common Mistake
The Trap: Treating UPF as documentation, like comments that describe the design.
- The tools execute every command. A typo in a strategy silently changes which cells get inserted and what the checkers look for.
Follow-up Question & Model Response
"What is the difference between the UPF-prime flow and the golden UPF flow?"
Candidate Model Response: In the UPF-prime flow, synthesis writes UPF' and P&R writes UPF'', each a mix of the original commands and tool changes. In the golden UPF flow, the original file never changes. Each tool writes its changes into a separate supplemental file, for example with save_upf -format supplemental (ICC2). Downstream tools read the golden file plus the supplemental file, which keeps your hand-written intent easy to review.
Practical Example
Design Scenario: (illustrative) MYCHIP has four domains: PD_MYCHIP (always-on, VDD1p0), PD_CPU (VDD0p9), PD_COP (switched VDD1p0_SW) and PD_DSP. The RTL for U_COP is identical whether PD_COP is switchable or not. Only design.upf decides that PD_COP gets a power switch, output isolation clamped to 0, and retention. Synthesis, ICC2 and PrimeTime all read the same design.upf, so all three agree that U_COP can turn off.
Low-Power & UPF Handbook
Master Low-Power VLSI & Multivoltage Design
Read the complete low-power guide library covering power domains, level shifters, isolation clamps, state retention, and UPF signoff verification.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising