Introduction to UPF

12 min read | Intermediate Level

What You'll Learn

• Understand what UPF is and its role in low-power design
• Learn the history and evolution of the IEEE 1801 standard
• Compare UPF with other power format specifications
• Recognize the benefits of using UPF in the design methodology

What is Unified Power Format (UPF)?

Unified Power Format (UPF) is a standardized language for specifying power intent in electronic designs. It provides a tool-independent way to describe:

• Power Domains: Groups of logic operating under common power control
• Supply Networks: Power and ground nets with their voltage levels
• Power Management Strategies: Isolation, retention, level shifting, and power gating
• Power States: Legal combinations of supply voltages and operating modes

UPF is written in Tcl syntax and consists of commands that annotate design netlists with power management information. Unlike RTL code that describes functional behavior, UPF describes power intent—how the design should behave with respect to power.

UPF files are separate from RTL code, allowing power architects to specify power management strategies without modifying the functional design. This separation of concerns improves design maintainability and enables independent verification of power and function.

Basic UPF Example

Here's a simple UPF specification showing fundamental concepts:

# Create the top-level power domain
create_power_domain PD_TOP -include_scope

# Create a power domain for CPU block
create_power_domain PD_CPU -elements {CPU_inst}

# Define supply nets
create_supply_net VDD_TOP -domain PD_TOP      # 1.0V supply for top
create_supply_net VDD_CPU -domain PD_CPU      # 0.9V supply for CPU
create_supply_net VSS -domain PD_TOP          # Common ground

# Create supply sets (groups of related supplies)
create_supply_set SS_TOP \
  -function {power VDD_TOP} \
  -function {ground VSS}

create_supply_set SS_CPU \
  -function {power VDD_CPU} \
  -function {ground VSS}

# Associate supply sets with domains
associate_supply_set SS_TOP -handle PD_TOP
associate_supply_set SS_CPU -handle PD_CPU

This example creates two power domains operating at different voltages (1.0V and 0.9V), demonstrating multi-voltage design—a common power optimization technique.

History and Evolution of UPF

UPF has evolved significantly since its inception, with each version adding capabilities for increasingly complex power management scenarios.

Early History: Pre-Standardization (Before 2007)

Before UPF, EDA vendors used proprietary formats:

• Cadence: Common Power Format (CPF)
• Synopsys: Power Compiler commands
• Mentor: Custom Tcl-based specifications

This fragmentation created significant challenges:

• Designs required multiple power specifications for different tools
• No guarantee of consistency across the flow
• Difficult to exchange designs between companies using different tools
• Verification of power intent was tool-specific

IEEE 1801-2009 (UPF v2.0): First IEEE Standard

In 2007, Accellera (now part of IEEE) initiated the UPF standardization effort (UPF v1.0), merging concepts from CPF and Synopsys formats. IEEE 1801-2009 was the first official standard, providing:

• Basic power domain creation and hierarchy
• Supply network specification
• Isolation and level shifter strategies
• Power state tables (PST)
• Retention strategies

IEEE 1801-2009 established the foundation that made UPF the industry-standard power format, gaining support from all major EDA vendors.

IEEE 1801-2013 (UPF v2.1): Enhanced Capabilities

The 2013 revision added significant enhancements:

• Repeater Strategies: Signal integrity for power domain crossings
• Enhanced PST: More expressive power state modeling
• Scope Management: Better handling of hierarchical designs
• Supply Set Handles: Improved supply network references
• Map Commands: Explicit control over cell mapping

IEEE 1801-2015 (UPF v3.0): Verification Focus

The 2015 update emphasized verification and IP integration:

• IP-XACT Integration: Standardized IP power metadata
• Verification Semantics: Clarified UPF interpretation for simulators
• Power-Aware UPF (PA-UPF): Enhanced simulation directives
• Model Usage: Better specification of when models apply

IEEE 1801-2018 (UPF v3.1): Complex hierarchical power intent

This revision includes:

• Low-Power IP Reuse: Improved partial UPF and IP composition
• Advanced Power Management: Fine-grained control for complex scenarios
• Clarifications: Resolved ambiguities from previous versions
• Tool Consistency: Better defined semantics for cross-tool compatibility

IEEE 1801-2024 (UPF v4.0): Mixed-signal and virtual supplies

This revision focuses heavily on interoperability and IP reuse:

• Value Conversion Methods (VCM) & Tunneling: Bridges the gap between analog/mixed-signal components and digital design by allowing power supplies to connect to arbitrary HDL types more flexibly.
• Refinable Macros: Allow IP providers to ship "soft IP" with power intent that can be refined by the end-user without modifying the original source code.
• Virtual Supplies: Introduces the concept of virtual supply nets and supply sets, to model power states and port constraints even when physical connections aren't yet defined in the implementation.

UPF vs Common Power Format (CPF)

Before UPF became the standard, Common Power Format (CPF) from Cadence was widely used. Understanding the differences helps appreciate UPF's advantages:

Similarities

• Both use Tcl syntax
• Both separate power intent from functional RTL
• Both support power domains, isolation, retention, and level shifting
• Both define power state tables

Key Differences

While CPF is still supported by Cadence tools for legacy designs, UPF has become the industry standard. Most new designs use UPF for maximum tool interoperability and future-proofing.

Benefits of Using UPF

Adopting UPF in your design methodology provides numerous advantages across the entire development cycle:

1. Tool Independence and Interoperability

UPF's standardization enables:

• Single power intent specification for all tools
• Freedom to choose best-in-class tools for each task
• Easier IP exchange between companies
• Reduced vendor lock-in

2. Consistency Across Design Flow

The same UPF file used for:

• RTL Simulation: Verify power state transitions and X-propagation
• Synthesis: Insert isolation, level shifters, retention cells
• Place & Route: Plan power domains, place switches, route supplies
• Power Analysis: Estimate power consumption per domain and state
• Formal Verification: Check power management correctness

Using identical UPF across the flow eliminates inconsistencies that could cause synthesis-simulation mismatches or implementation errors.

3. Separation of Concerns

UPF separates power intent from functional design:

• Functional Designers: Focus on RTL without power details
• Power Architects: Specify power strategy in UPF
• Independent Verification: Verify function and power separately
• Maintainability: Update power strategy without RTL changes

4. Early Power Planning

UPF enables early power exploration:

• Simulate power states before RTL is complete
• Estimate power savings from different strategies
• Identify power domain boundaries early
• Make architectural power decisions based on simulation data

5. Hierarchical and Modular Design

UPF supports complex hierarchies:

• Define power intent at IP block level
• Compose multiple UPF files at SoC level
• Reuse IP power specifications
• Override or extend power intent at integration

Limitations & Caveats

• Wildcard Interpretation Divergence: Tools have different "depths" for wildcards. Some tools treat * as non-recursive (searching only the current level), while others search through the entire sub-hierarchy.
• Semantic Drift Between Versions: UPF versions (1.0, 2.0, 3.1, 4.0) are not always fully backward compatible. For example, how "Power State Tables" (PSTs) are handled changed significantly between UPF 2.1 and 3.0.
• The "80/20" Design Wall: Most EDA tools can only optimize about 20% of a chip's power (mostly at the gate level). The other 80% is "locked in" by your RTL and architectural decisions. UPF cannot fix a bad architecture; it can only implement a good one efficiently.

6. Comprehensive Power Management

UPF supports all modern power techniques:

• Multi-voltage design (multiple V_dd levels)
• Power gating (shutoff unused blocks)
• State retention (preserve state during power-down)
• Isolation (prevent X-propagation)
• Level shifting (voltage domain crossing)
• Dynamic voltage/frequency scaling (DVFS)

Common Beginner Misconceptions

1. Architecture
   └─> Define power domains, voltage levels, power states

2. RTL Design
   └─> Write functional Verilog/SystemVerilog (no power-specific code)

3. UPF Specification
   └─> Create UPF file with power intent (parallel to RTL)

4. Simulation with UPF
   └─> Verify power state transitions, X-propagation, retention

5. Synthesis with UPF
   └─> Tool inserts isolation/level shifter/retention cells

6. Physical Design with UPF
   └─> Plan domains, place switches, route power grid

7. Power Analysis
   └─> Estimate power per domain and state

8. Signoff
   └─> Verify power management correctness

create_power_domain PD_TOP -include_scope
create_power_domain PD_GPU -elements {GPU_block}

create_supply_net VDD -domain PD_TOP -resolve final
create_supply_net VDD_GPU -domain PD_GPU
create_supply_net VSS

create_supply_set SS_TOP -function {power VDD} -function {ground VSS}
create_supply_set SS_GPU -function {power VDD_GPU} -function {ground VSS}

create_power_switch SW_GPU -domain PD_GPU \
  -input_supply_port {vin VDD} \
  -output_supply_port {vout VDD_GPU} \
  -control_port {ctrl pwr_en} \
  -on_state {on vin {ctrl}}

add_power_state VDD -state {ON 1.2}
add_power_state VDD_GPU -state {HIGH 1.1} -state {OFF off}

1. Number of Power Domains: 2
   - PD_TOP (top-level domain with all hierarchy)
   - PD_GPU (GPU block domain)

2. Supply Voltage Values:
   - VDD: 1.2V (always ON)
   - VDD_GPU: 1.1V (HIGH state) or OFF (power gated)
   - VSS: Ground (0V)

3. Power-Gated Domain: PD_GPU
   - SW_GPU is a power switch controlling VDD_GPU
   - VDD_GPU has an "OFF" state
   - Control signal "pwr_en" enables/disables power
   - PD_TOP remains always-on (no switch, no OFF state)