Skip to main content

Introduction

Verification's own power-aware verification page checked whether a design's power architecture behaves correctly — static structural checks, dynamic voltage-aware simulation — while explicitly declining to teach the syntax that actually describes that architecture in the first place: "not the UPF syntax used to author the power intent itself, which belongs to that not-yet-written topic." This is that topic.

Why power intent needs its own format at all​

RTL describes function — what a circuit computes, given its inputs. Nothing in plain SystemVerilog or Verilog describes which parts of that circuit can be independently powered down, what voltage each part runs at, or what has to happen at a domain boundary when one side loses power and the other doesn't. That information is genuinely separate from function — the same design could be split into power domains several different ways without changing what it computes at all — which is exactly why it doesn't belong embedded in the RTL itself. UPF (Unified Power Format) is a separate file, written alongside the RTL rather than inside it, describing exactly that: power domains, supply networks, legal power states, and the strategies (isolation, level shifting, retention, switching) that keep a multi-domain design correct as power changes. The relationship is the same one Timing Verification and STA's SDC file has to the design it constrains — layered intent, not code.

Where UPF actually came from​

UPF has a real, tellable origin story, directly parallel to UVM's own OVM/VMM lineage — a fragmented industry converging on one standard, not a single vendor's invention adopted wholesale:

  • 2006 — two competing efforts started almost simultaneously. Cadence's Power Forward Initiative, working through Si2's Low Power Coalition, began developing CPF (Common Power Format). Separately, a group led by Texas Instruments and Nokia brought a second effort to Accellera, which formed a committee to develop what became UPF.
  • January 2007 — both formats released their 1.0 specifications within weeks of each other: CPF 1.0 from Si2, UPF 1.0 from Accellera. The two shared roughly 90% of the same underlying concepts — power domains, isolation, retention — in genuinely incompatible syntax. This wasn't a disagreement about ideas; it was a competition over whose syntax the industry would standardize on.
  • 2008 — Accellera donated UPF to the IEEE P1801 working group. CPF continued on its own track through Si2 (CPF 1.1 in 2008, CPF 2.0 in 2011).
  • 2009 — IEEE published IEEE 1801-2009, informally "UPF 2.0" — the version that achieved broad multi-vendor EDA tool support and effectively settled the format competition. It added supply sets, the concept of successive refinement (power intent that starts abstract and gets filled in with physical detail later), and brought the total command count to 88.
  • 2013, 2015, 2018 — IEEE 1801-2013 (UPF 2.1, 11 new commands), IEEE 1801-2015 (UPF 3.0, system-level power support and a new information model), and IEEE 1801-2018 (UPF 3.1) followed as incremental refinements.
  • 2024 — IEEE 1801-2024 (UPF 4.0), six years after 3.1 — the longest gap between successive versions in the standard's history, reflecting a maturing standard rather than a neglected one. It introduced Refinable Macros (letting IP providers ship "soft IP" with power intent the end user refines later) and Virtual Supplies (abstract supply nets/sets that don't need to correspond to physical nets yet) — both direct extensions of the successive-refinement idea UPF 2.0 introduced fifteen years earlier.

Scope: authoring, not checking​

This topic teaches how to write UPF — the commands, their parameters, and the reasoning behind each one. It does not re-teach what Verification already covered: how a static checker validates that UPF against the netlist, or how a power-aware simulator exercises it dynamically. The two are companion topics, covering opposite sides of the same power architecture — this one produces the intent, that one checks it.

What's ahead​

Section B covers the four control strategies — isolation, level shifting, retention, and power switching — each solving a specific, concrete problem at a domain boundary. Section C covers assembling a complete power-up sequence, composing UPF hierarchically across a design, and a capstone writing real power intent for the PWM register block already built in UVM's RAL section.

What's next​

Before any strategy makes sense, the next page covers the two foundational constructs everything else in this topic builds on: power domains, and the supply networks that feed them.

Test Yourself on This Section