Power Mode And State

UPF and CPF diverge with hierarchical power intent; understanding this is critical to complex LP design.


By Luke Lang
Low-power designs that use power shutoff (PSO) and multiple-supply voltage (MSV) will have circuits that operate at various voltages, including no voltage. To describe the combination of allowable voltages in a design, CPF uses power mode, and UPF 1.0 uses power state.

In CPF, each power mode represents one combination of the states of all power domains. In UPF 1.0, each power state represents one combination of the voltages of all supply nets. It is much easier to explain this concept through an example.

Let’s assume we have the block below with 1.0 V always-on VDD (PDtop) driving into a power switch. The output of the power switch is VDD1 (PD1).


CPF is based on power domains. Because PD1 can operate at either 1.0V or shutoff, only two power modes are possible. They are:


UPF 1.0 is based on supply nets. Because VDD1 can operate at either 1.0V or shutoff, only two power states are possible. They are:


If we were to introduce MSV by allowing VDD to operate at 1.0 or 0.8V, then more rows can be added to the above tables to reflect the additional states. The only limitation is that PD1 must be in exactly the same state as PDtop if the power switch is on.

What I have discussed so far is commonly used by LP designers. While CPF and UPF 1.0 have different names and syntax, the concept is exactly the same. However, the similarity between power modes and power state ends when we start dealing with hierarchical power intent. In the example below, we instantiate the above block twice inside a top-level design.


Because the block-level power intent (CPF or UPF 1.0) already has been coded, we only need to code the top-level power intent. The rest of this blog will focus on the key differences between top-level CPF power mode and UPF 1.0 power state.

For UPF 1.0, the top-level design consists of only always-on VDD and VSS. Therefore, the top-level UPF file has only one power state.


With this coding, the top-level power state is totally decoupled from the block-level power states. This means that all possible block-level power states are allowed. For this example, there are four possible power states since u1/VDD1 and u2/VDD1 are independently switchable.

The UPF 1.0 top-level power state also can be coded to constrain the allowable block-level power states. This is done by adding a hierarchical reference to the block-level power net. For example, the following power state table says that the VDD1 power net inside block u1 cannot be switched off. However, it says nothing about the VDD1 power net inside block u2.


For CPF, the top-level power modes must completely specify all legal combinations of the power domains in the design, including the power domains in the sub-blocks. Therefore, the top-level power modes would look like:


If we were to constrain the VDD1 power net inside block u1 to be always-on, the top-level power modes would look like:


Comparing top-level CPF and UPF 1.0, I really like the simplicity of UPF 1.0 coding. However, the CPF coding with complete specification for all power domains has two main advantages.

  1. If we are only dealing with PSO domains inside the sub-blocks, a design with n blocks has 2n implicit power states. This could be a huge number if the tool does not know how to simplify the power states. With CPF, we can specify (n+1) power modes. The first mode has all of the power domains in the ON state. Subsequent power modes have one and only one power domain in the OFF state. This will cover all possible off-to-on domain crossings while limiting the number of power modes.
  2. For a MSV or dynamic-voltage frequency scaling (DVFS) design, each power mode can be associated with a unique set of clock frequencies. CPF’s update_power_mode command allows each power mode to be specified with a SDC file. This is a very powerful capability for today’s most complex LP designs requirement multi-mode, multi-corner (MMMC) timing analysis and optimization.

Hierarchical design methodology is absolutely necessary for today and tomorrow’s LP design. I hope this blog will help the readers navigate through hierarchical CPF and UPF 1.0.

Note: For this blog, I have purposely chosen to focus on the concepts and stayed away from syntax differences between CPF and UPF 1.0. Please refer to the CPF and UPF 1.0 Language Reference Manuals for the exact syntax.

— Luke Lang is engineering director at Cadence.

Leave a Reply

(Note: This name will be displayed publicly)