UPF Introduction: Understanding Unified Power Format for Design Verification

Mayur Kubavat · 23:27 · -- min read · Design Verification, IEEE 1801, Low Power, Power Intent, UPF,

This article covers UPF (Unified Power Format) — the industry-standard language for specifying power intent in modern chip designs. For Design Verification engineers, UPF knowledge directly affects the ability to catch power-related bugs before they become silicon failures.

What is UPF?

UPF (Unified Power Format) is a standardized specification language defined by IEEE 1801 for describing power intent in electronic designs. Power intent refers to the designer's intention for how power should be supplied, controlled, and managed across different parts of a chip.

UPF is not part of the RTL design itself. It exists as a separate specification that augments the functional design with power-related information. This separation follows the principle of orthogonal specification — keeping power intent independent from functional behavior allows the same RTL to be used with different power architectures.

UPF is based on Tcl (Tool Command Language), making it both human-readable and tool-executable. Every UPF command is a valid Tcl command, which means you can use Tcl constructs like variables, loops, and procedures within UPF files.

# UPF is valid Tcl - you can use variables and expressions
set cpu_domain_name "PD_CPU"
create_power_domain $cpu_domain_name -elements {u_cpu}

The Problem UPF Solves

Before UPF: The Fragmented Landscape

Prior to UPF standardization, power intent was communicated through multiple disconnected methods:

  1. Design Specification Documents: Power modes, voltage levels, and power-down sequences were described in Word or PDF documents. Engineers manually interpreted these documents and implemented power management in tools.
  2. RTL Comments and Attributes: Designers embedded power-related information as comments or synthesis attributes in RTL code. This was informal, non-executable, and prone to becoming stale.
  3. Proprietary Tool Formats: Each EDA vendor had their own format:
    • CPF (Common Power Format) — Cadence
    • Tool-specific TCL scripts — Various vendors
    Designs verified with one vendor's tools couldn't easily move to another.
  4. Manual Tool Configuration: Verification and implementation engineers manually configured power-aware behavior in each tool, leading to inconsistencies.

The Consequences

Problems from Fragmentation:
  • Implementation vs. Verification Mismatch: The power behavior verified in simulation didn't match what was implemented in silicon
  • Translation Errors: Manual interpretation of documents introduced bugs
  • No Golden Reference: When bugs were found, there was no authoritative source to determine correct behavior
  • Tool Lock-in: Proprietary formats prevented tool interoperability
  • Incomplete Verification: Power-related behaviors weren't systematically verified

The UPF Solution

UPF provides a single, executable specification that serves as the golden reference for power intent across the entire design flow:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#dbeafe', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#3b82f6', 'lineColor': '#64748b', 'secondaryColor': '#f1f5f9'}}}%%
flowchart TB
    UPF["UPF FILE
Single Source of Truth"]
    
    UPF --> SIM[Simulation
VCS, Xcelium, Questa]
    UPF --> SYN[Synthesis
DC, Genus]
    UPF --> PNR[Physical Implementation
ICC2, Innovus]
    
    SIM --> R1([Power-aware
simulation])
    SYN --> R2([Power-aware
netlist])
    PNR --> R3([Power-aware
layout])
    
    style UPF fill:#d1fae5,stroke:#10b981,stroke-width:2px
    style SIM fill:#dbeafe,stroke:#3b82f6
    style SYN fill:#dbeafe,stroke:#3b82f6
    style PNR fill:#dbeafe,stroke:#3b82f6
    style R1 fill:#f1f5f9,stroke:#94a3b8
    style R2 fill:#f1f5f9,stroke:#94a3b8
    style R3 fill:#f1f5f9,stroke:#94a3b8

IEEE 1801: The Official Standard

UPF is formally defined in IEEE Standard 1801, titled "IEEE Standard for Design and Verification of Low-Power, Energy-Aware Electronic Systems."

Version History and Evolution

Version IEEE Standard Year Significance
UPF 1.0 IEEE 1801-2009 2009 First IEEE standardization. Established core concepts: power domains, isolation, retention, level shifters. Based on Accellera UPF 1.0 (2007).
UPF 2.0 IEEE 1801-2009 2009 Part of same standard. Added supply networks, power states, formal supply modeling.
UPF 2.1 IEEE 1801-2013 2013 Introduced successive refinement, simstate, supply expressions, enhanced power state modeling. Significant for verification.
UPF 3.0 IEEE 1801-2015 2015 Added Liberty extensions, enhanced retention/isolation modeling, repeater support, macro modeling.
UPF 3.1 IEEE 1801-2018 2018 Improved supply set modeling, abstract power modeling for IP, verification enhancements.
UPF 4.0 IEEE 1801-2024 2024 Latest version with enhanced modeling capabilities.

Why Version Matters for DV Engineers

Different UPF versions have different verification semantics. Key differences that affect verification:

UPF 1.0 → 2.1 (simstate introduction):

Before simstate, simulators had inconsistent behavior for how to model powered-off logic. UPF 2.1 made this explicit and standardized.

# UPF 2.1 introduced simstate for explicit simulation semantics
add_power_state PD_CPU \
    -state ACTIVE {-supply_expr {power == FULL_ON} -simstate NORMAL} \
    -state SLEEP  {-supply_expr {power == OFF} -simstate CORRUPT} \
    -state OFF    {-supply_expr {power == OFF} -simstate OFF}
Note: Always specify your UPF version explicitly at the top of your file: 
upf_version 2.1  # Declare which version semantics to use

UPF vs. CPF: Understanding the History

You may encounter references to CPF (Common Power Format), especially in older designs or Cadence-centric flows.

Aspect UPF CPF
Origin Accellera (2007), then IEEE Cadence proprietary, then Si2
Standard IEEE 1801 Si2 (industry consortium)
Industry Adoption Dominant standard Declining, mostly legacy
Tool Support All major EDA vendors Primarily Cadence tools
Current Status Active development Maintenance mode
Recommendation: For new designs, use UPF. CPF is primarily encountered when working with legacy IP or older designs. Many tools can convert CPF to UPF.

Core Terminology

Understanding these fundamental terms:

Power Domain

A power domain is a grouping of design elements (instances, ports, nets) that share a common power supply and are controlled as a unit for power management. Elements within a power domain can be powered on or off together.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#dbeafe', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#3b82f6', 'lineColor': '#64748b', 'secondaryColor': '#f1f5f9'}}}%%
flowchart TB
    subgraph TOP["chip_top"]
        subgraph PD_CPU["PD_CPU"]
            CPU[u_cpu]
        end
        subgraph PD_GPU["PD_GPU"]
            GPU[u_gpu]
        end
        subgraph PD_AON["PD_AON (Always-On)"]
            AON[u_always_on]
        end
    end
    
    style PD_CPU fill:#dbeafe,stroke:#3b82f6
    style PD_GPU fill:#dbeafe,stroke:#3b82f6
    style PD_AON fill:#d1fae5,stroke:#10b981
    style TOP fill:#f1f5f9,stroke:#94a3b8

Supply Network

The supply network models the power delivery infrastructure: supply ports (where power enters), supply nets (power distribution), and supply sets (power/ground pairs). This is an abstract representation of the physical power grid.

Power State

A power state defines a specific operating condition characterized by supply voltage levels and functional mode. States can be ON, OFF, or intermediate (for voltage scaling).

Isolation

Isolation prevents unknown (X) values from propagating out of a powered-off domain. Isolation cells clamp outputs to known logic values (0 or 1) when the domain is off.

Retention

Retention preserves register state when a domain is powered off. Retention registers have shadow storage that maintains values during power-off, allowing state restoration on power-up.

Level Shifter

A level shifter converts signals between domains operating at different voltage levels. Required when signals cross voltage domain boundaries.

Why DV Engineers Need UPF Knowledge

1. UPF Directly Controls Simulation Behavior

When you run a power-aware simulation, the simulator reads the UPF file and modifies its behavior accordingly:

  • Register corruption: When a domain powers off, the simulator corrupts (sets to X) all non-retained registers in that domain
  • Output isolation: The simulator models isolation cells clamping domain outputs
  • Signal propagation: X values from powered-off domains propagate through the design unless isolated
Without understanding UPF, you cannot interpret what the simulator is doing during power transitions.

2. Power Bugs are Silicon Bugs

Power-related bugs found in silicon are among the most expensive to fix:

  • They often manifest as intermittent failures
  • They may only appear in specific power mode transitions
  • They can be masked during functional verification if power-aware simulation isn't properly configured

Common power bugs:

  • Missing isolation causing X propagation to always-on logic
  • Incorrect retention save/restore sequencing
  • Illegal power state transitions
  • Signals crossing powered-off domains

3. Power-Aware Coverage Requirements

Modern verification requirements include:

  • Coverage of all power state transitions
  • Verification of isolation enable/disable sequencing
  • Verification of retention save/restore behavior
  • Cross-domain signal integrity during power transitions

4. UPF Debugging is a DV Responsibility

When simulations show unexpected X values or incorrect behavior during power transitions, DV engineers:

  • Identify which UPF constructs are in effect
  • Determine if the issue is in RTL, UPF, or testbench
  • Verify that UPF correctly represents design intent

How UPF Integrates with Verification Flow

The following diagram shows how UPF integrates with the verification environment:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#dbeafe', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#3b82f6', 'lineColor': '#64748b', 'secondaryColor': '#f1f5f9'}}}%%
flowchart TB
    RTL[RTL Files]
    UPF["UPF File"]
    TB[Testbench]
    
    subgraph SIM["SIMULATOR"]
        DB[Design Database]
        PC[Power Controller]
        PM[Power Monitor]
        
        subgraph PA["Power-Aware Simulation"]
            S1["Supply state tracking"]
            S2["Corruption modeling"]
            S3["Isolation behavior"]
            S4["Retention save/restore"]
        end
        
        DB --> PA
        PC --> PA
        PM --> PA
    end
    
    RTL --> DB
    UPF --> PC
    TB --> PM
    
    PA --> OUT(["Power-Aware Results
Waveforms, Assertions, Coverage"])
    
    style UPF fill:#d1fae5,stroke:#10b981,stroke-width:2px
    style RTL fill:#dbeafe,stroke:#3b82f6
    style TB fill:#dbeafe,stroke:#3b82f6
    style SIM fill:#f1f5f9,stroke:#94a3b8
    style PA fill:#fef3c7,stroke:#f59e0b
    style OUT fill:#f1f5f9,stroke:#94a3b8

Testbench Responsibilities

Your testbench handles:

1. Power supply control: Drive supply ports to model power-on/off

// Testbench controls supply state
supply_ctrl.vdd_cpu = 1'b0;  // Power off CPU domain

2. Power management signals: Drive isolation enables, retention save/restore

// Proper power-down sequence
iso_en_cpu <= 1'b1;      // Enable isolation first
#10;
save_cpu <= 1'b1;        // Save retention state
#10;
supply_ctrl.vdd_cpu = 0; // Then power off

3. Power protocol verification: Check correct sequencing of control signals

4. X value handling: Expect and handle X values from powered-off domains

UPF File Organization

A well-structured UPF file follows a logical order:

#=============================================================================
# 1. VERSION AND SCOPE DECLARATION
#=============================================================================
upf_version 2.1
set_design_top top_module

#=============================================================================
# 2. SUPPLY NETWORK DEFINITION
#=============================================================================
# Supply ports, nets, and their connections

#=============================================================================
# 3. POWER DOMAIN DEFINITION
#=============================================================================
# Create power domains and assign elements

#=============================================================================
# 4. SUPPLY CONNECTIONS
#=============================================================================
# Connect supplies to domains

#=============================================================================
# 5. POWER STATE DEFINITION
#=============================================================================
# Define states for supplies and domains

#=============================================================================
# 6. POWER MANAGEMENT STRATEGIES
#=============================================================================
# Isolation, retention, level shifting rules

#=============================================================================
# 7. POWER STATE TABLE (Optional)
#=============================================================================
# Legal combinations of domain states

Summary

  1. UPF is IEEE 1801 — an industry-standard, tool-independent format for specifying power intent
  2. UPF is separate from RTL — it augments the design with power information without modifying functional code
  3. UPF is executable — simulators and implementation tools directly consume UPF to drive power-aware behavior
  4. UPF is the single source of truth — one specification drives verification, synthesis, and implementation
  5. Version matters — UPF 2.1 introduced simstate for verification semantics; always specify your version
  6. DV engineers use UPF to understand simulation behavior and catch power bugs before silicon

Up Next: Supply Networks

In the next article, we'll cover Supply Networks — how to model power delivery with create_supply_net, create_supply_port, and supply states.

This article is part of the UPF & Low Power Verification series for Design Verification Engineers.

Author
Mayur Kubavat
VLSI Design and Verification Engineer sharing knowledge about SystemVerilog, UVM, and hardware verification methodologies.

Comments (0)

Leave a Comment