What is the difference between UPF (IEEE 1801) and CPF (Si2) as power-intent languages, and why did the industry converge on UPF?
From PDVerse Low-Power Physical Design Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
UPF and CPF are both Tcl-based languages that describe power intent outside the RTL: domains, supplies, isolation, level shifting, retention and power states. UPF started at Accellera and became IEEE 1801, while CPF came from the Si2 consortium with Cadence behind it. The industry settled on UPF because an IEEE standard gave every tool vendor a single target, and Cadence tools now read UPF too, so a UPF file travels across vendors.
Technical Explanation
- Same job: both keep power intent in a side file so the RTL stays unchanged when domains or strategies change.
- UPF history: Accellera UPF 1.0 in 2007, then IEEE 1801-2009 (UPF 2.0, which added supply sets and power states), 1801-2013 and 1801-2015.
- CPF history: Si2 released CPF 1.0 in 2007 from a Cadence contribution and kept revising it outside IEEE.
- CPF centers on power modes and mode transitions; UPF 1801-2015 describes states per supply set and domain with
add_power_state(UPF). - Command names overlap, such as a
create_power_domaincommand in both, but option names and meaning differ, so files are not interchangeable. - Mixed flows need a translator or a rewrite, and translation errors show up as missing isolation or wrong supplies.
- Today most new designs write UPF; CPF appears mainly in legacy IP and older Cadence-based flows.
# [UPF] design.upf
create_power_domain PD_COP -elements {U_COP} -supply {primary SS_COP}
# [CPF] Cadence format, for comparison only
create_power_domain -name PD_COP -instances {U_COP} -shutoff_condition {!U_PC/PSE}Common Mistake
The Trap: Assuming CPF and UPF files map line for line because the command names look alike.
- Options such as the shutoff condition in CPF have no one-line UPF equivalent; UPF needs a power switch, supply set and power states.
- A naive conversion drops that shutdown behavior, and the tools then see PD_COP as always on and skip isolation.
Follow-up Question & Model Response
"You inherit an IP block with a CPF file. What do you do?"
Candidate Model Response: First check whether your tool chain reads CPF at all; Synopsys flows expect UPF. If not, rewrite the intent in UPF 1801-2015 form rather than trusting a blind translation. Rebuild the domains, supply sets, switch, isolation and retention strategies, and the power states. Then run a static low-power check on both versions against the same netlist and compare the missing isolation and level shifter reports before signing off. Keep the original CPF under version control as the reference for the IP owner's intent.
Practical Example
Design Scenario: (illustrative) A legacy CPF file for coprocessor IP U_COP declares PD_COP with a shutoff condition on !U_PC/PSE and three power modes. The SoC flow is Synopsys-based, so the team rewrites it in UPF: create_power_domain (UPF) with a primary supply set SS_COP, a create_power_switch (UPF) driven by U_PC/PSE, set_isolation (UPF) on PD_COP outputs and add_power_state (UPF) for ON and OFF. A static check on the new UPF finds two outputs the CPF isolation rule had covered by a wildcard that the rewrite missed, and the team adds them before handoff. From then on the UPF file is the only power intent the flow reads, and the CPF stays archived as reference.
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