Hierarchical UPF

15 min read | Advanced Level

What You'll Learn

• Distinguish between top-down and bottom-up UPF specification approaches
• Use the load_upf command to integrate hierarchical UPF files
• Apply scope management techniques for hierarchical power domains
• Organize UPF files for IP reuse and team collaboration

The Hierarchical UPF Challenge

Modern SoC designs integrate hundreds of IP blocks from different sources: in-house developed subsystems, licensed third-party IP, and vendor-supplied blocks. Each subsystem may have complex internal power management with multiple voltage domains, power states, and control strategies.

Consider a mobile application processor integrating:

• CPU cluster: 12 cores with per-core power gating
• GPU subsystem: 64 execution units with voltage scaling
• Video codec: Encoder and decoder with retention
• AI accelerator: Custom IP with multi-voltage design
• Memory controller: DDR4/LPDDR5 with power-down modes

Attempting to capture all power intent in a single monolithic UPF file creates serious problems:

• File sizes exceed 5,000+ lines, becoming unmanageable
• IP blocks cannot be reused - power intent tied to specific instance names
• Teams cannot work in parallel - everyone modifies the same file
• Vendor IP arrives with proprietary UPF that must be manually merged
• Changes to one subsystem risk breaking others

Hierarchical UPF solves these problems by allowing each subsystem to define its own power intent in separate files, which are then composed at integration using scoping and supply mapping.

Top-Down vs. Bottom-Up UPF Approaches

Two fundamental strategies exist for hierarchical UPF organization: top-down specification and bottom-up composition.

Top-Down UPF Specification

In the top-down approach, a single UPF file at the chip's top level defines power intent for all hierarchy levels. The integrator has complete visibility and control over the entire power architecture.

# top_level.upf - Top-down approach
# Define all power domains from top level

# Top-level domain
create_power_domain PD_TOP -include_scope

# CPU subsystem domains (defined from top)
create_power_domain PD_CPU -elements {cpu_subsystem}
create_power_domain PD_CORE0 -elements {cpu_subsystem/core_0}
create_power_domain PD_CORE1 -elements {cpu_subsystem/core_1}
create_power_domain PD_L2 -elements {cpu_subsystem/l2_cache}

# GPU subsystem domains (defined from top)
create_power_domain PD_GPU -elements {gpu_subsystem}
create_power_domain PD_GPU_CORE -elements {gpu_subsystem/gpu_core}
create_power_domain PD_GPU_MEM -elements {gpu_subsystem/gpu_memory}

# Video codec domains (defined from top)
create_power_domain PD_VIDEO -elements {video_codec}
create_power_domain PD_VIDEO_DEC -elements {video_codec/decoder}
create_power_domain PD_VIDEO_ENC -elements {video_codec/encoder}

# All supply networks and power switches defined here
create_supply_net VDD
create_supply_net VDD_CPU
create_supply_net VDD_GPU
# ... hundreds more lines ...

Advantages of Top-Down:

• Complete visibility of entire power architecture in one place
• Easier to ensure global consistency across all domains
• Simpler debugging with single file
• No scope management complexity

Disadvantages of Top-Down:

• Monolithic files become unmanageable (thousands of lines)
• No IP reuse - power intent tied to specific instance names
• Parallel development blocked - all teams must coordinate edits
• Changes to one subsystem require modifying entire file
• Version control conflicts when multiple engineers work simultaneously

Bottom-Up UPF Specification

In the bottom-up approach, each hierarchical block defines its own UPF file with local power intent. These files are loaded and composed at the top level using the load_upf command.

# cpu_subsystem.upf - CPU team's independent UPF file
# Defines power intent relative to cpu_subsystem scope

# Primary power domain (relative to this scope)
create_power_domain PD_CPU -include_scope

# Sub-domains within CPU subsystem
create_power_domain PD_CORE0 -elements {core_0}
create_power_domain PD_CORE1 -elements {core_1}
create_power_domain PD_L2 -elements {l2_cache}

# Supply networks local to CPU subsystem
create_supply_net VDD_CPU
create_supply_net VSS
create_supply_net VDD_CORE0
create_supply_net VDD_CORE1

# Power switches for CPU cores
create_power_switch PSW_CORE0 -domain PD_CORE0 \
  -input_supply_port {vin VDD_CPU} \
  -output_supply_port {vout VDD_CORE0} \
  -control_port {ctrl core0_power_enable} \
  -on_state {on vin {ctrl}}

# ... rest of CPU-specific power intent ...

# gpu_subsystem.upf - GPU team's independent UPF file

create_power_domain PD_GPU -include_scope
create_power_domain PD_GPU_CORE -elements {gpu_core}
create_power_domain PD_GPU_MEM -elements {gpu_memory}

# GPU uses multiple voltage states for DVFS
create_supply_net VDD_GPU
add_power_state VDD_GPU \
  -state {HIGH 1.0} \
  -state {MED 0.9} \
  -state {LOW 0.8} \
  -state {OFF off}

# ... GPU-specific power management ...

# top_level.upf - Top-level integration file
# Loads subsystem UPF files and connects supplies

create_power_domain PD_TOP -include_scope

# Load CPU subsystem UPF into its scope
load_upf cpu_subsystem.upf -scope cpu_subsystem

# Load GPU subsystem UPF into its scope
load_upf gpu_subsystem.upf -scope gpu_subsystem

# Load video codec UPF
load_upf video_codec.upf -scope video_codec

# Define top-level supply networks
create_supply_net VDD -domain PD_TOP
create_supply_net VSS -domain PD_TOP

# Connect top-level supplies to subsystem supplies
set_domain_supply_net PD_TOP -primary_power_net VDD
set_domain_supply_net PD_TOP -primary_ground_net VSS

Advantages of Bottom-Up:

• Modular organization - each subsystem in separate file
• IP reuse - UPF files travel with IP blocks
• Parallel development - teams work independently
• Easier maintenance - changes localized to affected subsystem
• Scalable to large SoCs with 100+ blocks
• Vendor IP integration without manual merging

Disadvantages of Bottom-Up:

• Scope management complexity
• Harder to visualize global power architecture
• Potential naming conflicts between subsystems
• Debugging requires tracking across multiple files
• Supply mapping adds integration overhead

Most production SoCs use a hybrid approach: bottom-up for major IP blocks and subsystems, top-down for interconnect and glue logic. This balances modularity with control.

The load_upf Command

The load_upf command is the foundation of hierarchical UPF, loading a UPF file and applying it within a specified scope.

Syntax

load_upf  \
  -scope  \
  [-supply_map ] \
  [-replace] \
  [-relative]

Parameters

• filename: Path to UPF file to load
• -scope: Hierarchical instance to apply UPF to
• -supply_map: File mapping subsystem supply names to top-level names
• -replace: Replace existing UPF for this scope (useful for updates)
• -relative: Interpret paths relative to load location

Basic load_upf Example

# Load CPU subsystem UPF
load_upf cpu_subsystem.upf -scope cpu_subsystem

# Load GPU subsystem UPF with supply mapping
load_upf gpu_subsystem.upf \
  -scope gpu_subsystem \
  -supply_map gpu_supply_map.txt

# Load video codec UPF with replacement
# (useful when updating IP with new power intent)
load_upf video_codec_v2.upf \
  -scope video_codec \
  -replace

Supply Mapping

When a subsystem's internal supply names don't match the top-level supply names, use a supply map file to translate names during load.

# gpu_supply_map.txt - Maps GPU internal names to top-level names
# Format:  

VDD_GPU_INTERNAL     VDD_GPU
VSS_GPU_INTERNAL     VSS
VDD_GPU_CORE_INTERNAL VDD_GPU_CORE
VDD_GPU_MEM_INTERNAL  VDD_GPU_MEM

# top_level.upf
# Apply supply mapping when loading GPU UPF
load_upf gpu_subsystem.upf \
  -scope gpu_subsystem \
  -supply_map gpu_supply_map.txt

# Now GPU's VDD_GPU_INTERNAL references top-level VDD_GPU

Supply mapping is essential for third-party IP blocks that use different naming conventions than your design. It enables integration without modifying the vendor's UPF file, preserving IP integrity and enabling future updates.

Scope Management in Hierarchical UPF

Scope determines the hierarchical context for UPF commands. Proper scope management is critical for hierarchical UPF organization.

set_scope Command

set_scope 

Changes the current scope for subsequent UPF commands. Use . to return to the top level, and .. to move up one level.

# Start at top level
create_power_domain PD_TOP -include_scope

# Create CPU domain
create_power_domain PD_CPU -elements {cpu_subsystem}

# Enter CPU subsystem scope
set_scope cpu_subsystem

# Now in cpu_subsystem scope - create domains relative to here
create_power_domain PD_CORE0 -elements {core_0}
create_power_domain PD_CORE1 -elements {core_1}
create_power_domain PD_L2 -elements {l2_cache}

# Return to top level
set_scope .

# Create GPU domain at top level
create_power_domain PD_GPU -elements {gpu_subsystem}

# Enter GPU scope
set_scope gpu_subsystem

# Create GPU sub-domains
create_power_domain PD_GPU_CORE -elements {gpu_core}
create_power_domain PD_GPU_MEM -elements {gpu_memory}

# Return to top level
set_scope .

Absolute vs. Relative Paths

Hierarchical paths can be absolute (from top) or relative (from current scope).

# Absolute path (from top level, starts with /)
create_power_domain PD_CORE0 -elements {/cpu_subsystem/core_0}

# Relative path (from current scope, no leading /)
set_scope cpu_subsystem
create_power_domain PD_CORE0 -elements {core_0}  # Relative to cpu_subsystem

Best Practice: Subsystem UPF files should use relative paths to enable IP reuse. The same UPF file should work regardless of the instance name at the top level.

UPF File Organization Strategies

Several strategies exist for organizing UPF files in hierarchical designs. The choice depends on design size, team structure, and IP reuse requirements.

Strategy 1: One File Per IP Block

Each reusable IP block has its own UPF file that travels with the RTL.

File structure:
ip_blocks/
  cpu_cortex_a78/
    rtl/
    upf/
      cpu_cortex_a78.upf
  gpu_mali_g78/
    rtl/
    upf/
      gpu_mali_g78.upf
  video_codec_h265/
    rtl/
    upf/
      video_codec.upf

soc_top/
  upf/
    top_level.upf
    supply_maps/
      cpu_supply_map.txt
      gpu_supply_map.txt

Advantages: IP portability, clear ownership, easy reuse across projects

Disadvantages: Requires supply mapping for integration

Strategy 2: Hierarchical Layer Files

Separate UPF files for each hierarchy level, with clear naming convention.

upf/
  l0_top.upf              # Top level
  l1_cpu_cluster.upf      # CPU cluster
  l1_gpu_subsystem.upf    # GPU subsystem
  l1_video_codec.upf      # Video codec
  l2_cpu_core.upf         # Individual CPU core
  l2_gpu_core.upf         # GPU core
  l2_gpu_memory.upf       # GPU memory

Advantages: Clear hierarchy visualization, systematic naming

Disadvantages: Less portable for IP reuse

Strategy 3: Functional Separation

Separate UPF files by function: domains, supplies, power management, constraints.

upf/
  domains.upf           # All create_power_domain commands
  supplies.upf          # All supply networks and ports
  power_switches.upf    # All power gating
  level_shifters.upf    # All level shifters
  isolation.upf         # All isolation strategies
  retention.upf         # All retention strategies
  power_states.upf      # All power state definitions

# top_level.upf loads all these files

Advantages: Easy to find specific type of specification, good for debugging

Disadvantages: Doesn't support IP reuse, load order dependencies

# top_level.upf - Main integration file for mobile SoC

# Top-level scope
create_power_domain PD_TOP -include_scope

# Load subsystem UPF files with appropriate supply mappings
# CPU cluster (4x Cortex-A78 cores)
load_upf ../ip_blocks/cpu_cortex_a78/upf/cpu_cluster.upf \
  -scope cpu_cluster \
  -supply_map supply_maps/cpu_supply_map.txt

# GPU subsystem (Mali-G78)
load_upf ../ip_blocks/gpu_mali_g78/upf/gpu_subsystem.upf \
  -scope gpu_subsystem \
  -supply_map supply_maps/gpu_supply_map.txt

# Video codec (H.265 encoder/decoder)
load_upf ../ip_blocks/video_codec_h265/upf/video_codec.upf \
  -scope video_codec \
  -supply_map supply_maps/video_supply_map.txt

# AI accelerator (custom IP)
load_upf ../ip_blocks/ai_accelerator/upf/ai_accelerator.upf \
  -scope ai_accel \
  -supply_map supply_maps/ai_supply_map.txt

# Memory subsystem (DDR4 controller + LPDDR5)
load_upf memory_subsystem.upf -scope memory_subsystem

# Interconnect fabric (NoC)
load_upf noc_interconnect.upf -scope noc

# Define top-level supply networks
create_supply_net VDD_SYS     # System supply: 1.8V always-on
create_supply_net VDD_CPU     # CPU supply: 0.8V-1.1V (DVFS)
create_supply_net VDD_GPU     # GPU supply: 0.7V-0.9V (DVFS)
create_supply_net VDD_VIDEO   # Video supply: 0.9V
create_supply_net VDD_AI      # AI accelerator: 0.85V
create_supply_net VDD_MEM     # Memory: 1.1V
create_supply_net VSS         # Ground

# Create supply sets for top level
create_supply_set SS_TOP \
  -function {power VDD_SYS} \
  -function {ground VSS}

associate_supply_set SS_TOP -handle PD_TOP

# Isolation between major subsystems
set_isolation ISO_CPU_TO_NOC -domain cpu_cluster \
  -isolation_supply_set SS_TOP \
  -clamp_value 0 \
  -isolation_signal cpu_iso_enable \
  -location parent

set_isolation ISO_GPU_TO_NOC -domain gpu_subsystem \
  -isolation_supply_set SS_TOP \
  -clamp_value 0 \
  -isolation_signal gpu_iso_enable \
  -location parent

# Level shifters at subsystem boundaries
set_level_shifter LS_CPU_OUTPUTS -domain cpu_cluster \
  -applies_to outputs \
  -location parent

set_level_shifter LS_GPU_OUTPUTS -domain gpu_subsystem \
  -applies_to outputs \
  -location parent

# WRONG: Loading power management before domains exist
load_upf power_switches.upf    # Error: domains don't exist yet
load_upf domains.upf

# CORRECT: Load domains first, then power management
load_upf domains.upf
load_upf supplies.upf
load_upf power_switches.upf

# WRONG: Absolute path in cpu_subsystem.upf (breaks reusability)
create_power_domain PD_CORE0 -elements {/top/cpu_subsystem/core_0}
# This won't work if CPU is instantiated as "cpu_cluster"

# CORRECT: Use relative paths for IP reuse
create_power_domain PD_CORE0 -elements {core_0}
# Works regardless of instance name at top level

# WRONG: Loading GPU UPF without supply mapping
load_upf gpu_subsystem.upf -scope gpu_subsystem
# Error: GPU's VDD_GPU_INTERNAL doesn't exist at top level

# CORRECT: Provide supply mapping
load_upf gpu_subsystem.upf \
  -scope gpu_subsystem \
  -supply_map gpu_supply_map.txt

# WRONG: Not returning to top scope
set_scope cpu_subsystem
create_power_domain PD_CORE0 -elements {core_0}
# Still in cpu_subsystem scope!
create_power_domain PD_GPU -elements {gpu_subsystem}  # Error!

# CORRECT: Return to top scope before creating GPU domain
set_scope cpu_subsystem
create_power_domain PD_CORE0 -elements {core_0}
set_scope .  # Return to top
create_power_domain PD_GPU -elements {gpu_subsystem}

# wifi_supply_map.txt
VDD_WIFI_INTERNAL  VDD_WIRELESS
VSS_WIFI_INTERNAL  VSS

# bluetooth_supply_map.txt
VDD_BT_INTERNAL  VDD_WIRELESS
VSS_BT_INTERNAL  VSS

# nfc_supply_map.txt
VDD_NFC_INTERNAL  VDD_WIRELESS
VSS_NFC_INTERNAL  VSS

# wireless_subsystem.upf - Subsystem integration file

# Primary wireless domain
create_power_domain PD_WIRELESS -include_scope

# Always-on RF front-end domain
create_power_domain PD_RF -elements {rf_frontend}

# Load vendor IP UPF files with supply mapping
load_upf wifi_ip.upf \
  -scope wifi \
  -supply_map wifi_supply_map.txt

load_upf bluetooth_ip.upf \
  -scope bluetooth \
  -supply_map bluetooth_supply_map.txt

load_upf nfc_ip.upf \
  -scope nfc \
  -supply_map nfc_supply_map.txt

# Define wireless subsystem supplies
create_supply_net VDD_WIRELESS
create_supply_net VDD_RF_ALWAYS_ON
create_supply_net VSS

# Supply sets for wireless domain
create_supply_set SS_WIRELESS \
  -function {power VDD_WIRELESS} \
  -function {ground VSS}

associate_supply_set SS_WIRELESS -handle PD_WIRELESS

# Supply set for always-on RF domain
create_supply_set SS_RF_ALWAYS_ON \
  -function {power VDD_RF_ALWAYS_ON} \
  -function {ground VSS}

associate_supply_set SS_RF_ALWAYS_ON -handle PD_RF

# Define power states for RF (always on)
add_power_state VDD_RF_ALWAYS_ON -state {ON 0.9}
# Note: No OFF state - RF is always powered

# Define power states for wireless (can be gated)
add_power_state VDD_WIRELESS \
  -state {ON 1.0} \
  -state {OFF off}

# Power switch for wireless domain (RF stays on)
create_power_switch PSW_WIRELESS -domain PD_WIRELESS \
  -input_supply_port {vin VDD_RF_ALWAYS_ON} \
  -output_supply_port {vout VDD_WIRELESS} \
  -control_port {ctrl wireless_power_enable} \
  -on_state {on vin {ctrl}}

# Isolation for wireless outputs (using always-on supply)
set_isolation ISO_WIRELESS -domain PD_WIRELESS \
  -isolation_supply_set SS_RF_ALWAYS_ON \
  -clamp_value 0 \
  -isolation_signal wireless_iso_enable \
  -location parent

# top_level.upf - Top-level integration snippet

# Load wireless subsystem
load_upf wireless_subsystem.upf \
  -scope wireless_subsystem \
  -supply_map wireless_supply_map.txt

# wireless_supply_map.txt contents:
# VDD_WIRELESS       VDD_WIRELESS_SYS
# VDD_RF_ALWAYS_ON   VDD_RF_SYS
# VSS                VSS

# Level shifters for wireless subsystem outputs
set_level_shifter LS_WIRELESS -domain wireless_subsystem \
  -applies_to outputs \
  -location parent