Back to ChipVerify AI

Learn / Concept

Low-Power RTL and UPF Basics

Modern SoCs save power by switching parts of the chip off, running blocks at different voltages, and waking them back up where they left off. None of that lives in the RTL — the RTL is deliberately power-agnostic. The power intent lives in a separate file written in UPF (Unified Power Format, IEEE 1801), and the special cells that make power gating safe — isolation, level shifters, retention — are inserted and checked from that intent. This page walks through power domains, power switches, isolation cells, level shifters, and retention registers, the bugs that bite when one of them is missing, and what static UPF checking can and cannot tell you.

Power intent and the UPF file

A UPF file is a small Tcl program that describes how a design is powered without touching the RTL. It declares which logic belongs to which power domain, which supply nets feed each domain, where the power switches sit, and which crossings need isolation, level shifting, or retention. Keeping intent separate from function means the same RTL can be reused across products with different power architectures, and it gives the tools one authoritative source to insert and verify low-power cells against. The snippet below shows a switchable core domain with a power switch, an isolation clamp, and retention.

# Minimal UPF: a switchable domain with isolation + retention.
# The RTL stays power-agnostic; this file carries the power intent.

# Two power domains: an always-on top and a switchable core.
create_power_domain PD_TOP
create_power_domain PD_CORE -elements {u_core}

# Primary supply for the always-on domain.
create_supply_port  VDD      -domain PD_TOP
create_supply_net   VDD      -domain PD_TOP
create_supply_net   VDD_SW   -domain PD_CORE

# Power switch: gate VDD into the core's switched rail.
create_power_switch core_sw \
  -domain        PD_CORE \
  -output_supply_port {vout VDD_SW} \
  -input_supply_port  {vin  VDD} \
  -control_port  {sleep pwr_ctrl.sleep_n} \
  -on_state      {on vin {!sleep}}

# Isolation: clamp core outputs to 0 while PD_CORE is down,
# enabled by the always-on iso_en, so no floating value escapes.
set_isolation core_iso \
  -domain          PD_CORE \
  -isolation_power_net VDD \
  -clamp_value     0 \
  -applies_to      outputs
set_isolation_control core_iso \
  -domain   PD_CORE \
  -isolation_signal pwr_ctrl.iso_en \
  -isolation_sense  high

# Retention: hold core state across power-down on the always-on VDD.
set_retention core_ret \
  -domain          PD_CORE \
  -retention_power_net VDD
set_retention_control core_ret \
  -domain    PD_CORE \
  -save_signal    {pwr_ctrl.save  high} \
  -restore_signal {pwr_ctrl.restore high}

Power domains and power switches

A power domain is a group of logic that shares a supply and a power state — it powers up and down together. An always-on domain stays powered whenever the chip is alive; it hosts the power controller and the always-on shadow logic that other cells depend on. A power switch (header or footer) gates the supply into a switchable domain, turning its rail on and off under control of the power controller. The instant you can turn a domain off, every signal leaving that domain becomes a question: what value does the rest of the chip see while the domain is dark?

Isolation cells: clamp value and enable

When a domain powers down, its outputs float to an unknown value. If that value drives a powered-on domain, the unknown propagates as an X and corrupts live logic. An isolation cell sits on the crossing and clamps the signal to a known constant — its clamp value, 0 or 1 — while the source domain is off. Two things must be right: the clamp value has to be the safe constant for that signal (a request line usually clamps to 0; an active-low ready may clamp to 1), and the isolation enable has to be driven from an always-on supply with the correct polarity and sequencing, so the clamp is in force before the source goes dark and released only after it is back. An isolation cell with the wrong enable, or no enable at all, is worse than none — it looks present but does not protect.

Level shifters

A level shifter translates a signal between domains running at different voltages. A net leaving a 0.6 V domain cannot be read reliably by a 0.9 V receiver without one: the logic levels do not line up, and the result is degraded noise margin or outright failure. Level shifting is a voltage problem, isolation is a power-state problem, and a crossing between a switchable low-voltage domain and an always-on high-voltage domain can need both cells, in the right order. Missing level shifters are a classic power-aware bug precisely because a functionally correct simulation at a single nominal voltage never exercises the mismatch.

Retention registers and always-on logic

Powering a domain off normally loses its state. A retention register keeps a small always-on shadow element that holds the flop’s value through the power-down, so the block resumes from where it stopped instead of resetting. The controller issues a save before the switch opens and a restore after the rail is back, and that sequencing — relative to the isolation enable and the power switch — has to be exact. Retention costs area and always-on leakage, so it is applied selectively to the state that genuinely must survive sleep: configuration, control FSMs, counters. The retention control, the isolation enable, and the power-switch control all live in always-on logic, which is itself never gated.

Common power-aware bugs

  • Missing isolation on a power-down crossing. A signal leaves a switchable domain into a powered-on one with no clamp, so the receiver samples an X when the source sleeps. Often invisible until silicon, because nominal-voltage simulation never powers the domain off.
  • Bare or mis-enabled isolation. An isolation cell is present but its enable comes from a gated supply, has the wrong polarity, or asserts at the wrong time — so the clamp is not actually in force during the power-down window.
  • Unretained state that must survive sleep. A control register or counter that has to persist across power-down is built from ordinary flops, so the block wakes into a corrupt or reset state.
  • Missing level shifter on a multi-voltage crossing. A net crosses between domains at different voltages with no shifter, eroding noise margin and failing under voltage corners that a single-voltage run never reaches.
  • Save/restore sequencing errors. Retention save and restore, isolation enable, and the power switch fire in the wrong order, so retained state is captured or released outside its valid window.

What static UPF checking can — and cannot — tell you

Static, structural UPF checking reads the power intent and the RTL together and answers a specific, bounded question: of the signals that cross between power domains, which crossings have the isolation, level shifting, and retention the power-state rules require, and which do not? It can report the coverage of power-domain crossings — named crossings with and without protection, with file and line — and surface bare or mis-enabled isolation and unretained state that should survive sleep. What it does not do is run the power-up and power-down sequences in time, measure dynamic or leakage power, or close timing on the always-on net. It is structural evidence, not a dynamic check and not a foundry power signoff.

How ChipVerify checks this

ChipVerify AI runs static, structural low-power analysis from the UPF and the RTL together: it identifies the power-domain crossings, checks which ones carry isolation and retention where the power-state rules require them, and reports the coverage — the protected crossings and the gaps — with file-and-line evidence and an honest note on what it could not resolve. This is pre-signoff structural evidence that complements power-aware simulation and the commercial low-power flow. It is not a dynamic power-aware run, not a power signoff, and not a certification.

FAQ

What is UPF?

UPF (Unified Power Format, IEEE 1801) is a Tcl-based language that captures the power intent of a design separately from the RTL. It declares power domains, supply nets and ports, power switches, and the special cells — isolation, level shifters, retention — that the synthesis and verification tools must insert and check at power-domain crossings. The RTL stays power-agnostic; the UPF says how it is powered.

What is the difference between an isolation cell and a level shifter?

An isolation cell clamps a signal to a known constant (0 or 1) while its source domain is powered down, so a floating, unknown value never propagates into a powered-on domain. A level shifter translates a signal between two domains that run at different voltages, so a 0.6 V output is driven cleanly into a 0.9 V receiver. They solve different problems — one for power state, one for voltage level — and a crossing can need both.

What is a retention register and when do you need one?

A retention register has a small always-on shadow latch that holds the flop's value through a power-down of its main domain, so the block resumes from saved state instead of resetting. You need retention wherever a powered-down block must wake up and continue rather than restart — control state, configuration, counters. Retention costs area and always-on power, so it is applied selectively, and the save/restore sequencing has to be right.

Can static UPF checking replace power-aware simulation or signoff?

No. Static UPF checks are structural: they confirm that the crossings declared by the UPF and RTL have isolation, level shifting, and retention where the power-state rules require them, and they flag crossings that do not. They do not run the power-up/power-down sequences, do not measure dynamic or leakage power, and are not a foundry signoff. They are pre-signoff evidence that complements power-aware simulation and the commercial low-power signoff flow, not a substitute for either.

Related reading

Check isolation and retention coverage on your UPF

Sign in and point ChipVerify AI at your RTL and UPF. It runs static, structural low-power analysis, names the power-domain crossings with and without isolation and retention, and returns file-and-line evidence — pre-signoff structural analysis, not a dynamic power-aware run or a foundry power signoff.