Power Intent Specification (UPF/CPF)

Power intent specification is the practice of describing a chip's low-power architecture in a formal, machine-readable file that the design tools read alongside the logic description. A modern low-power design partitions its logic into regions that can be switched off, run at reduced voltage, or retain their state through a shutdown. None of this structure appears in a register-transfer-level description written in a hardware description language, which captures only logical behavior. The power intent file supplies the missing information: it names the power domains, defines the supply networks that feed them, lists the special cells that must be inserted at domain boundaries, and enumerates the legal combinations of supply states. With this file, synthesis, place-and-route, and verification tools can build and check the power architecture automatically instead of relying on manual, error-prone insertion of low-power structures.

Two standard formats express power intent. The Unified Power Format (UPF) is the more widely used; it was developed by Accellera, contributed to the IEEE, and standardized as IEEE 1801, which subsequent revisions have extended. The Common Power Format (CPF) originated in an electronic-design-automation vendor's Power Forward Initiative, was contributed to the Silicon Integration Initiative for standardization, and remains associated chiefly with that vendor's flow. Both formats describe the same underlying concepts, and both are written as scripts in the Tool Command Language, so a power intent file reads as a sequence of commands that progressively define the design's power architecture. This article uses generic terminology and notes format-specific differences where they matter, then traces how the specification is consumed across the implementation and verification flow.

The Need for Power Intent

A register-transfer-level description expresses what a circuit computes, not how it is powered. It assumes, implicitly, that every gate receives a single, always-on supply. Low-power techniques violate this assumption. Power gating removes the supply from idle blocks; multiple-voltage design runs different blocks at different voltages; state retention preserves selected registers through a power-down. Each technique requires physical structures, such as switches, level shifters, isolation gates, and retention registers, that the logical description does not contain and cannot imply.

Before standardized power formats existed, engineers added these structures by hand and tracked the power architecture in documents and scripts that the tools could not read or check. The approach did not scale and was a frequent source of silicon failures, because a single missing isolation cell or an out-of-order power sequence can corrupt a chip. A formal power intent file solves this by making the power architecture an explicit, tool-readable input. The same file drives every stage of the flow, so the intent verified at the register-transfer level is the intent that synthesis implements and that equivalence checking confirms in the final netlist. The specification thus serves as the single, authoritative source of the design's power architecture, kept separate from but applied consistently to the functional description.

Power Domains

A power domain is a collection of logic elements that share a common set of supply conditions and are powered, switched, and controlled as a unit. The power domain is the central organizing concept of a power intent specification; almost every other construct is defined relative to a domain. A specification begins by creating domains and assigning portions of the logic hierarchy to each, so that the tools know which gates belong together for the purpose of power control.

Domains are commonly classified by how their supply behaves. An always-on domain receives power whenever the chip is powered and contains the logic that must never lose state, such as the power-management controller, the real-time clock, and the wake-up circuitry. A switchable domain can have its supply removed to save leakage power when its function is idle, and it is restored when the function is needed again. Domains may also differ in voltage, with one domain operating at a higher voltage for performance and another at a lower voltage for efficiency. Because a domain defines the granularity of power control, its boundaries are chosen to group logic with shared activity patterns, and signals that cross between domains receive the special treatment described in the following sections.

Supply Networks and Power States

Beyond grouping logic, a power intent specification describes the electrical supply that feeds each domain. It declares supply nets, which carry power and ground, and supply ports, through which power enters the design or a domain. It declares power switches, the devices that connect or disconnect a switchable domain's supply under the control of an enable signal, and it identifies the control signal that operates each switch. UPF expresses these elements through explicit supply nets, ports, and set-related power-supply constructs, building an electrically meaningful model of how current reaches each domain; CPF expresses equivalent information through its own power-mode and supply commands. This supply model lets the tools reason about which domains are live under any given condition and verify that every gate has a defined supply in every operating mode.

An important refinement is the distinction between a supply being on, off, or at a particular voltage. A supply net is modeled with a state and, where relevant, a voltage value, so that the tools can determine not merely whether a domain is powered but at what level. This information underlies the checks that level shifters are present wherever voltages differ and that isolation is present wherever a powered domain could receive signals from an unpowered one.

Level Shifters and Isolation Cells

Signals that cross the boundary between domains require special cells, and a principal purpose of the power intent specification is to declare where and how these cells are inserted.

Level Shifters

A level shifter translates a logic signal from the voltage of one domain to the voltage of another. When a signal driven at a low voltage enters a domain operating at a higher voltage, the receiving gates may not recognize it as a valid logic level, and the mismatch can leave input transistors partly conducting, wasting power or producing incorrect values. A level shifter restores a clean signal at the destination voltage. The power intent specification states the strategy for inserting level shifters, identifying which domain crossings need them and the direction of translation, so the implementation tools place the appropriate cells automatically rather than relying on a designer to find every crossing by hand.

Isolation Cells

An isolation cell holds a signal at a known, valid logic value when the domain that drives it is powered down. The output of an unpowered domain is electrically undefined and would otherwise propagate an indeterminate value into the domains that remain active, corrupting their operation. An isolation cell, typically a gate that clamps the signal to a fixed level, is placed on each signal that leaves a switchable domain and is enabled by a control signal before the source domain powers down. The specification defines the isolation strategy for each domain, including the clamp value and the control signal that activates isolation, so that every output crossing from a switchable domain is protected. Correct ordering, isolating before powering down and de-isolating after powering up, is part of the power sequencing that the specification and its associated control logic must enforce.

State Retention

Powering a domain down and back up normally loses all the state held in its registers, which must then be reinitialized, costing time and energy and, in some cases, making power gating impractical. State retention preserves selected state across a power-down so that a domain can resume quickly from where it left off. The power intent specification declares the retention strategy that achieves this.

Retention relies on retention registers, which contain a low-leakage shadow storage element kept alive by an always-on supply while the main register and the surrounding logic lose power. Before the domain powers down, a save operation transfers each register's value into its shadow element; after power returns, a restore operation copies the value back, reconstituting the domain's state. The specification names the registers or domain to which retention applies, the save and restore control signals and their timing, and the always-on supply that keeps the shadow elements alive. Because retention cells cost area and a small amount of leakage, designers apply retention selectively to the state that genuinely must survive, allowing the rest to be reinitialized; the specification is where that selection is recorded so the tools insert retention exactly where intended.

Power State Tables

Defining domains and supplies establishes what can be controlled, but it does not say which combinations of supply states are legal. A complex chip has many domains, and the arbitrary product of their individual on, off, and voltage settings would describe far more combinations than the design actually supports or intends. The power state table enumerates the legal combinations explicitly. Each entry, often called a power state or power mode, names one valid system condition and lists the state of every supply in that condition, for example a full-performance mode with all domains on at high voltage, a low-power mode with non-essential domains off, and a deep-sleep mode in which only the always-on domain remains powered.

The power state table is central to both implementation and verification. It bounds the space of conditions the tools must consider, so that checks for missing level shifters and isolation are performed against the combinations that can actually occur rather than every theoretical permutation. It also documents the design's intended power-management behavior in a form the tools can act upon, and it provides the reference against which dynamic verification confirms that the control logic only ever drives the chip into states the table declares legal. UPF expresses these combinations with add-power-state constructs, while CPF uses power-mode definitions, but in both formats the table is the authoritative list of the operating conditions the power architecture must support.

Role Across the Implementation and Verification Flow

A defining characteristic of power intent specification is that one file drives the entire design flow, so that the same intent is implemented and checked consistently from the register-transfer level through to the final layout. The file is read at each stage and refined as the design becomes more physical.

Synthesis and Implementation

During logic synthesis, the tool reads the specification together with the register-transfer-level description and builds the power architecture into the gate-level netlist, inserting isolation cells, level shifters, and retention registers according to the declared strategies and mapping registers to retention cells where required. In physical implementation, place-and-route tools use the same intent, now augmented with technology-specific detail, to place power switches, construct the power distribution network for each domain, position the boundary cells correctly relative to the domains they serve, and respect the physical constraints of the power architecture. Because the structures are inserted by tools from a single declarative source rather than coded by hand, they are consistent and complete by construction.

Verification

Verification of power intent proceeds along two complementary lines. Static checking, performed without simulation, analyzes the specification and the design to confirm structural correctness: that every signal crossing a voltage boundary has a level shifter, that every output of a switchable domain has isolation, that retention is applied where the power state table requires it, and that the supply model is consistent. Dynamic verification simulates the design with the power intent applied, so that domains genuinely lose and regain state, isolation clamps engage, and retention saves and restores; this exposes errors in the sequencing and control of power transitions, such as isolating too late or restoring before the supply is stable, that static analysis cannot find. Finally, because synthesis and optimization transform the netlist, power-aware equivalence checking confirms that the implemented low-power netlist remains logically equivalent to the verified register-transfer-level design, ensuring that inserting the power structures did not alter the intended function. Through these stages the specification provides the common reference that keeps intent, implementation, and verification aligned.

Comparing UPF and CPF

UPF and CPF target the same problem and share the same essential concepts of power domains, supply networks, boundary cells, retention, and legal power states, yet they differ in origin, ownership, and detail. UPF is an open IEEE standard, IEEE 1801, maintained through Accellera and the IEEE and supported broadly across the industry's tools; its successive revisions have expanded its modeling of supplies and its support for incremental and hierarchical specification. CPF arose from a single vendor's Power Forward Initiative, was standardized through the Silicon Integration Initiative's Low Power Coalition, and remains most closely associated with that vendor's environment. Both are written in the Tool Command Language and applied as commands that build up the power architecture, so a practitioner familiar with one recognizes the structure of the other.

The practical differences lie in command syntax and in the precise modeling of supplies, boundary conditions, and power states, which means a specification generally cannot be moved between the formats without translation, and a project commits to one format consistent with its chosen tool flow. The industry has converged toward UPF as the open standard, and it is the format most commonly encountered in new designs, but the underlying discipline is identical: capture the power architecture once, formally and separately from the logic, and let that single source drive and verify every stage of implementation.

Summary

Power intent specification captures a chip's low-power architecture in a formal, tool-readable file that supplies the structure a register-transfer-level description omits. UPF, standardized as IEEE 1801, and CPF, from the Silicon Integration Initiative, both express this intent as Tool Command Language commands that define power domains, the supply networks and power switches that feed them, and the legal operating conditions of the design. The specification declares where level shifters translate signals between voltages, where isolation cells clamp the outputs of domains that power down, and where retention preserves state through a shutdown. A power state table enumerates the legal combinations of supply states, bounding what the tools implement and verify. One specification drives the whole flow: synthesis and place-and-route insert the power structures from it, static checking confirms their structural correctness, dynamic simulation validates the sequencing of power transitions, and power-aware equivalence checking confirms that the low-power netlist still matches the intended logic. By making power intent explicit, formal, and consistently applied, the specification turns an error-prone manual practice into an automated, verifiable part of digital design.

Electronics Guide