VLSI / Power Integrity / UPF & IPF
Power Integrity · Power Intent & Power Data

UPF & IPF

Two file formats, two very different jobs, one letter apart. UPF (Unified Power Format, IEEE 1801) is the industry-standard language for describing power intent — what power domains exist, what voltages they run at, and how they're gated, isolated, and retained — written early and carried through simulation, synthesis, and place-and-route. IPF (Instance Power File) is a RedHawk-SC/PrimePower-specific data format that carries actual per-instance power numbers — the measured or estimated output of a power analysis tool — into static IR-drop and electromigration signoff. This page covers both in depth, with real syntax and real example data for each.

Introduction

UPF vs IPF at a Glance

Both formats are Tcl-based, both are about power, and both feed into the same broader power-integrity signoff process this documentation set already covers — but they operate at opposite ends of the design flow and answer completely different questions.

Where UPF and IPF sit in the flow Architecture domains & voltages RTL Design no power code → open page UPF written here power domains, supplies, isolation, retention, level shifters, power states IEEE 1801 standard Simulation + Synthesis UPF drives cell insertion → open page Physical Design domains, switches placed → open page Power Analysis (PrimePower etc.) computes real instance power IPF generated here per-instance power numbers, .ipf file RedHawk-SC / PrimePower IPF feeds directly into static IR-drop & EM signoff UPF is written once, early, by architects/power leads — it describes intent and is consumed by every downstream tool. IPF is generated late, per-run, by a power estimation tool — it's data, re-created every analysis iteration.

Click a stage to open its page or section. UPF answers "what power architecture should this chip have?" and is authored by hand early in the flow. IPF answers "how much power is this specific instance actually drawing right now?" and is machine-generated late in the flow, directly feeding the Static Analysis signoff stage.

UPFIPF
Full nameUnified Power FormatInstance Power File
Standard?Yes — IEEE 1801, vendor-neutralNo — tool-specific (Synopsys PrimePower / Ansys RedHawk-SC ecosystem)
What it describesPower intent: domains, voltages, gating, isolation, retentionPower data: measured/estimated watts or amps per instance per pin
Who writes itPower architect / RTL team, by hand, earlyGenerated automatically by a power analysis tool, late
Consumed bySimulators, synthesis, place-and-route, formal toolsRedHawk-SC's PowerView, for static IR-drop/EM analysis
UPF Fundamentals

Power Domains & Supply Sets

Everything in UPF builds on two primitives: a power domain groups logic that shares common power control, and a supply set groups the actual power/ground nets that feed a domain. UPF is layered on top of RTL without touching it — the same Verilog gets different power behavior depending only on which UPF file is loaded alongside it.

⤢ Click to zoom Two power domains: always-on top, gated GPU PD_TOP — always-on (create_power_domain PD_TOP -include_scope) SS_TOP: power=VDD_TOP (1.2V), ground=VSS PD_GPU (elements: gpu_inst) SS_GPU: power=VDD_GPU, ground=VSS add_power_state VDD_GPU -state {ACTIVE 0.9} -state {OFF off} gpu_inst logic Rest of chip (in PD_TOP scope) CPU / always-on logic I/O / control logic associate_supply_set connects a supply set to a domain; a power domain with no switch is implicitly always-on.

PD_GPU is a sub-region of the chip that can be gated independently of PD_TOP — its own supply net, its own supply set, its own power states.

Building it up, command by command

# Create the top-level power domain (always-on context)
create_power_domain PD_TOP -include_scope

# Create a power domain scoped to just the GPU instance
create_power_domain PD_GPU -elements {gpu_inst}

# Define supply nets (the actual power/ground rails)
create_supply_net VDD_TOP -domain PD_TOP      # 1.2V supply for top
create_supply_net VDD_GPU -domain PD_GPU      # switchable supply for GPU
create_supply_net VSS     -domain PD_TOP      # common ground

# Group related supplies into a named supply set
create_supply_set SS_TOP -function {power VDD_TOP} -function {ground VSS}
create_supply_set SS_GPU -function {power VDD_GPU} -function {ground VSS}

# Attach each supply set to its domain
associate_supply_set SS_TOP -handle PD_TOP
associate_supply_set SS_GPU -handle PD_GPU
CommandWhat it does
create_power_domain-include_scope covers the entire current hierarchy scope (typical for the top domain); -elements {...} lists specific instances to include (typical for a sub-block domain)
create_supply_netDeclares one physical power or ground net and which domain it belongs to
create_supply_setGroups a power net and a ground net under one named handle via -function {power ...} / -function {ground ...}, so later commands (isolation, retention, level shifters) can reference "the supply for this domain" in one argument instead of two
associate_supply_setConnects a supply set to a domain's primary power handle — without this, the domain has no defined power source
UPF Fundamentals

Power States & Power Switches

A power state is a named, legal voltage value a supply net can take (add_power_state); a power switch is the UPF object that models the actual header/footer switch cell controlling whether a domain's supply is connected to an upstream always-on rail (create_power_switch). Together they're what makes a domain "power-gateable" instead of just multi-voltage.

# Power states: legal voltage values for each supply
add_power_state VDD_TOP -state {ON 1.2}
add_power_state VDD_GPU -state {ACTIVE 0.9} -state {OFF off}

# Power switch: models the physical header/footer switch cell
create_power_switch PSW_GPU -domain PD_GPU \
  -input_supply_port  {vin  VDD_TOP} \
  -output_supply_port {vout VDD_GPU} \
  -control_port       {ctrl gpu_power_enable} \
  -on_state            {on vin {ctrl}}

Reading the switch: vin is the always-on input rail, vout is the switched output that actually feeds PD_GPU, and ctrl is the enable signal. The -on_state {on vin {ctrl}} clause says "the output is in the 'on' state, driven from vin, whenever the control condition is true" — when gpu_power_enable deasserts, vout (and therefore VDD_GPU) has no valid on-state and the domain is off.

Where this connects: the physical header/footer switch cells this UPF describes are exactly the power-gating hardware discussed under Floorplanning and planned into the power delivery network on the main Power Integrity page — UPF is the specification, physical design is the implementation.
Power Management Strategy

Isolation Strategies

When a power domain is gated off, its outputs float to an undefined value. If that undefined signal reaches always-on logic, it can corrupt computation, cause shoot-through current (both PMOS and NMOS conducting at an intermediate voltage), or make a receiving flip-flop metastable. Isolation cells sit at the boundary and clamp the domain's outputs to a known-safe value (0 or 1) whenever the domain is off — and critically, the isolation cells themselves are powered by the always-on supply, not the domain being gated, so they keep functioning after the domain they're isolating has lost power.

⤢ Click to zoom Without isolation Gated domain VDD = OFF X Always-on logic corrupted / shoot-through Floating output propagates an undefined value into live logic With isolation Gated domain VDD = OFF ISO clamp→0 powered by VDD_TOP Isolation cell (always-on) clamps output to a safe, known value Power-down sequence 1. Assert isolation (clamp engages) → 2. Wait for isolation to settle → 3. De-assert power enable → 4. Domain off, output safely clamped Power-up reverses the order: power on → wait for VDD stable → release reset → THEN de-assert isolation. Never disable isolation before power/reset are stable.

Isolation must be asserted before power-down and released only after power and reset are stable on the way back up — getting this sequencing backward is one of the most common real UPF bugs.

set_isolation ISO_GPU -domain PD_GPU \
  -isolation_supply_set SS_TOP \
  -clamp_value 0 \
  -isolation_signal gpu_iso_enable \
  -isolation_sense high \
  -location parent
ParameterMeaning
-isolation_supply_setMust be an always-on supply set (e.g. SS_TOP) — using the gated domain's own supply here is the single most common beginner mistake, since the isolation cell would lose power right when it's needed
-clamp_value0 or 1 — the safe value to drive when isolated. Active-high enables typically clamp to 0 (disabled); active-low signals like reset_n typically clamp to 1 (stays out of reset)
-isolation_signal / -isolation_senseThe control signal and its active polarity (high or low) that triggers clamping
-locationparent (most common) places the cell in the always-on domain just outside the boundary; self places it inside the gated domain; fanout places one per receiving instance
Common mistake: -isolation_supply_set SS_GPU instead of SS_TOP — the isolation cell would be powered by the exact domain it's supposed to isolate, so it clamps nothing the moment it's actually needed. Always point isolation supply at the parent/always-on domain.
Power Management Strategy

Retention Strategies

Power gating a domain normally loses every flip-flop's state, forcing a slow software re-initialization on wake (milliseconds). Retention adds a second, always-on, low-voltage supply (typically 0.6–0.8V) to specially-built retention flip-flops, so state is preserved through a power-down cycle at near-zero leakage and restored in microseconds instead of milliseconds — the difference between a phone waking instantly on touch versus visibly lagging.

⤢ Click to zoom Retention flip-flop: dual supply VDD_CPU (1.0V) switchable, normal operation Retention FF 1.3–1.5× area of a standard flip-flop VDD_RET (0.6V, always-on) Power-down / power-up sequence 1. Assert save/retention signal → FF switches from VDD_CPU to VDD_RET 2. Power switch opens → VDD_CPU off, combinational logic leakage ≈ zero 3. Retention cell holds state at 0.6V (just above data-loss threshold) 4. Wake: VDD_CPU restored → wait stable → de-assert retention → FF resumes Total wake time: microseconds (vs. milliseconds without retention) Cost: 30–50% area overhead per retained FF — use -elements to retain only critical state

Retention only preserves flip-flop state, not combinational logic — the domain can still be fully powered off for maximum leakage savings everywhere except the deliberately-retained registers.

# Retention supply: a second, always-on, low-voltage net
create_supply_net VDD_RET -domain PD_CPU
create_supply_set  SS_CPU_RET -function {power VDD_RET} -function {ground VSS}
add_power_state    VDD_RET -state {RETENTION 0.6}

# Basic retention: every flip-flop in the domain
set_retention RET_CPU -domain PD_CPU \
  -retention_supply_set SS_CPU_RET \
  -retention_condition {cpu_retention_enable}

# Selective retention: only the state actually worth saving
set_retention RET_CRITICAL -domain PD_CPU \
  -retention_supply_set SS_CPU_RET \
  -retention_condition {retention_enable} \
  -elements {
    cpu_inst/control_unit/config_regs
    cpu_inst/control_unit/status_regs
    cpu_inst/mmu/tlb_state
  }

Selective retention (via -elements) is the practical default in real designs: retaining every flip-flop costs 30–50% extra area on each one, so teams typically retain only control/status registers and re-initialize bulk datapath state (ALU operands, temporary buffers) on wake, since that state is cheap to recompute anyway.

Common mistake: pointing -retention_supply_set at the domain's own switchable supply instead of a dedicated always-on retention net — if the retention cell's power comes from the same rail that's about to be switched off, there's nothing left to hold the state.
Power Management Strategy

Level Shifters

When a signal crosses from one voltage domain into another, the receiving domain's gates may not correctly interpret the sender's voltage swing. A signal driven at 0.9V arriving at a 1.2V domain's input may not register as a clean logic-1 (low-to-high crossing); a 1.2V signal driving directly into 0.6V gates can overstress the thin oxide of the smaller-voltage transistors (high-to-low crossing). Level shifter cells sit at these domain boundaries and translate the voltage swing so the receiving domain sees a clean, full-rail signal.

⤢ Click to zoom Level shifting across a voltage domain crossing PD_LOW (0.9V) signal swings 0 ↔ 0.9V Level Shifter L→H (up-shift) PD_HIGH (1.2V) clean signal swings 0 ↔ 1.2V High-to-low crossings need level shifters too — without one, an oversized swing can overstress the receiving domain's thinner gate oxide

Level shifting is orthogonal to isolation: isolation deals with a domain being off, level shifting deals with two domains that are both on but at different voltages.

set_level_shifter LS_LOW_TO_HIGH -domain PD_LOW \
  -applies_to outputs \
  -rule low_to_high \
  -location parent

Like isolation, -location parent is the typical choice, placing the level shifter cell just outside the source domain so it's driven by a supply that's guaranteed available. Many real designs need level shifters in both directions simultaneously if a domain both sends signals to a higher-voltage neighbor and receives signals from it — -rule can be set to low_to_high, high_to_low, or both depending on the crossing.

Methodology

UPF in the Design Flow

UPF is written early and reused, unmodified, by every downstream tool — that consistency is the entire point of standardizing it.

Flow stageHow UPF is used
ArchitecturePower domains, voltage levels, and power states are decided before RTL is even complete
RTL designFunctional Verilog/SystemVerilog is written with no power-specific code — UPF stays a separate file
SimulationPower-aware simulation verifies power state transitions, X-propagation behavior, and retention save/restore against the UPF model
SynthesisThe tool inserts real isolation, level-shifter, and retention library cells wherever UPF strategies say they're needed — see Logic Synthesis
Physical designPower domains are planned into the floorplan, power switches are placed, and the power grid is routed to match — see Floorplanning
Power analysisPer-domain, per-state power is estimated — this is where IPF data starts to appear, feeding IR-drop/EM signoff
SignoffPower management correctness (isolation/retention/level-shifter presence and sequencing) is checked formally against the same UPF used from day one
Why this separation matters: using the identical UPF file across simulation, synthesis, and physical design eliminates the synthesis-simulation mismatches that plagued pre-standardization flows, when Cadence's Common Power Format (CPF), Synopsys's proprietary Power Compiler commands, and Mentor's Tcl specifications each described the same intent slightly differently.
RedHawk-SC / PrimePower

IPF: Instance Power File

Where UPF describes intent, IPF carries data: a flat text file listing how much power (or current) every instance in the design actually draws, generated by a power-estimation tool — typically Synopsys PrimePower — and consumed by RedHawk-SC's PowerView object for static IR-drop and electromigration signoff (see Static Analysis). RedHawk-SC supports two IPF layouts, a detailed 9-column form and a simpler 3-column form.

⤢ Click to zoom Two supported IPF layouts 9-column format # instance_name power_pin voltage # toggle_rate frequency total_power # switching_power internal_power leakage_power inst_129902 VDD 1.2000 0.2000 781249984.0 0.005 0.0 0.005 0.0 inst_129995 VDD 1.2000 0.5835 390624992.0 3.37e-5 1.08e-5 2.29e-5 6.46e-9 inst_130106 VDD 1.2000 0.0584 390624992.0 1.66e-6 1.44e-6 2.20e-7 1.65e-9 Full breakdown per pin: separates switching, internal, and leakage power components 3-column format # instance_name pin_power_W Vdd_pin_name # instance_name pin_current_A Vss_pin_name U1/U1 8e-8 VDD U1/U2 1e-8 VDD Just total power (or current) per pin — simpler, useful when only aggregate power is known, e.g. imported from a 3rd-party power estimate

Real example lines, reproduced from Synopsys/Ansys RedHawk-SC application-note documentation. Instances with no entry in the IPF file are silently assigned zero power — coverage gaps are a real, common signoff risk.

Column (9-column format)Meaning
instance_nameHierarchical path to the cell instance
power_pin_nameWhich supply pin this power number applies to (e.g. VDD)
voltageOperating voltage at that pin (V)
toggle_rateSwitching activity factor used to derive dynamic power
frequencyClock frequency the toggle rate is referenced to (Hz)
total_powerSum of switching + internal + leakage power (W)
switching_powerPower from charging/discharging the net's load capacitance
internal_powerPower dissipated inside the cell itself during switching (short-circuit current, internal node charging)
leakage_powerStatic power drawn even when the cell isn't switching

IPF in the static power flow

RedHawk-SC's PowerView is, in effect, a lightweight version of a full scenario view that only tracks instance power — it can import a hand-off IPF file directly, calculate power itself from a SwitchingActivityView's toggle rates, or convert currents from an existing analysis. When it imports IPF, coverage matters: the appnote is explicit that instances missing from the file get zero assigned power, so an incomplete IPF silently under-counts real power draw unless a fallback switching-activity-driven flow is layered on top for uncovered instances.

# Load a design's IPF file into a PowerView for static analysis
pwr = db.create_power_view(dv=dv, power_file_names='power.ipf.gz', tag='pwr')

# Use that PowerView in a static scenario for IR-drop / EM signoff
scn = db.create_scenario_view(power_view=pwr, scenario_type='Static',
                                options=options, voltage_levels=voltage_levels, tag='scn')

# ...later, export an IPF back out of a PowerView (e.g. after adjustment)
# PowerView.write_instance_power_file(file_name, comment=None)

Multiple IPF files can be combined in one power_files list, each scoped to a specific instance_name, cell_name, or with a scaling_factors dict to rescale a particular supply net's contribution — and exactly one file in the list can be marked 'override': True to take precedence if the same instance appears in more than one source file.

Where this connects: IPF-based static power is one of four ways RedHawk-SC can source instance power for the Static Analysis stage — the others being toggle-rate-driven SwitchingActivityView, SAIF-based, and VCD/FSDB-based flows. IPF is the path used when a separate power-signoff tool (PrimePower) has already computed authoritative per-instance numbers upstream.
Recap

UPF vs IPF, Side by Side

QuestionUPF answers itIPF answers it
What voltage does this domain run at?Yes — add_power_stateNo
Can this domain be turned off?Yes — create_power_switchNo
What happens to this domain's outputs when it's off?Yes — set_isolationNo
Does this domain remember its state across power-down?Yes — set_retentionNo
How many watts is this specific instance drawing right now?NoYes — per-instance power/current values
Where in the design is IR drop or EM risk highest?No (indirectly, via domain structure)Yes — feeds directly into static IR-drop/EM signoff
Is it a public standard?Yes — IEEE 1801No — Synopsys/Ansys tool ecosystem format

In short: without UPF, a chip's power architecture has no formal, tool-independent description at all. Without IPF (or one of RedHawk-SC's other power-sourcing methods), the static IR-drop and EM analysis on the EMIR Analysis page has no per-instance power numbers to work from in the first place. They're not competing formats — they're sequential dependencies in the same signoff chain.

Sources