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 · pdVerse Mentor Guide
Definition
UPF (Unified Power Format, standardized as IEEE 1801) and CPF (Common Power Format, from the Si2 consortium) are two competing industry-standard languages for describing a design's power intent — power domains, supply nets, isolation/level-shifter/retention strategies, and power state tables — separately from the design's functional RTL; UPF is the format that has become the dominant, IEEE-standardized industry choice, while CPF, though technically similar in purpose, has seen its usage decline in favor of UPF.
Mentor Explanation
Both languages solve the same underlying problem — RTL alone has no native way to express "this block can be powered off, this signal boundary needs isolation, this register needs to retain state through a power-down" — and both were developed and championed by different EDA vendor coalitions in the mid-to-late 2000s (UPF originating from Accellera/Synopsys-aligned tools, CPF from Cadence/Si2-aligned tools), leading to a period where a design team had to pick one and largely commit their EDA tool flow to it, since cross-format translation was imperfect. Over time the industry converged on UPF specifically because it achieved formal IEEE standardization (IEEE 1801), which gave it broader multi-vendor tool support and reduced the risk of being locked into one vendor's flow — a pattern common in EDA standards, where the IEEE/Accellera-standardized option tends to win out over a single-consortium proprietary format even when the technical capabilities are comparable.
Example
A legacy design block acquired from a team that used an older Cadence-centric flow might still carry a .cpf power-intent file rather than a .upf file — recognizing that this file serves exactly the same role as a UPF file (defining domains, supplies, isolation, retention) is the practical skill, even if translating or re-authoring it in UPF is the modern path forward.
Why It Matters
Knowing that CPF exists (and why it lost out) matters less for daily UPF authoring than for understanding why UPF looks the way it does and why virtually every modern low-power tool flow (ICC2, PrimeTime, Fusion Compiler, and others) treats UPF as the default power-intent format — it also matters if you ever encounter a legacy design or an older tool flow still using CPF, so you recognize it as the same category of artifact (power intent) rather than assuming it's something else entirely.
Command
# Illustrative side-by-side of equivalent intent (syntax differs, concept identical):
# UPF: create_power_domain PD1 -elements {U1 U2}
# CPF: create_power_domain -name PD1 -instances {U1 U2} (CPF's equivalent construct)Common Beginner Mistake
Assuming CPF is simply "an older, worse version of UPF" with no real technical capability, rather than understanding it as a competing standard that addressed the same problem with comparable technical depth — the reason UPF won out was standardization and tool-ecosystem breadth (IEEE 1801, broad multi-vendor adoption), not a fundamental technical gap between the two languages.
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.
Continue practising