Copyright © 2006 Penton Media, Inc., All rights reserved.
Printing of this document is for personal use only.
Reprints

Now that there are two competing industry formats to capture power intent for low-power designs—the Common Power Format (CPF) and the Unified Power Format (UPF)—design teams need to understand the similarities and differences between the two. A few design companies may be able to ignore one format or the other, but most design companies will use both formats.

The first reference to the CPF file format came in early 2006, when Cadence announced its Power Forward Initiative. In late 2006, Cadence and the Silicon Integration Initiative (Si2) created the Low Power Coalition (LPC) under Si2’s auspices to develop the CPF format.

In January 2007, LPC released the first public document containing the CPF format definition. That document is available at www.si2.org. Cadence’s tool suite supports CPF, and several EDA vendors also support the format as defined in the LPC document. At DAC 2006, a number of other companies, led by Texas Instruments and Nokia, met to create a second format with broader EDA company support. The project was dubbed the Unified Power Format, and Accellera formed a committee to hammer out the details.

In January 2007, Accellera released its UPF 1.0 specification. This document is available at www.accellera.org. In January 2008, Magma, Mentor, and Synopsys jointly announced support for UPF in their tools. And once again, a number of other EDA vendors also supports the format.

During 2007, IEEE established a working group to create an industry-standard power-intent format. This standard will be called IEEE-P1801. The working group accepted donations of existing formats as a starting point. Accellera donated UPF, but Cadence did not donate CPF.

A draft of the format is expected to be available at DAC 2008. There’s hope it will be ratified by late 2008. In many ways, P1801 is an improvement of UPF. One way to think about P1801 is as “UPF version 1.1.” (For more on the history of these formats, see “Power-Intent Standards Vie For Designers’ Loyalties” at www.electronicdesign.com, ED Online 18123.)

FORMAT SIMILARITIES
The CPF and UPF formats have 90% of the same concepts using completely different syntaxes. But all of the main aspects of power intent for low-power design can be captured in either format. Both formats are based around Tcl, the tool control language embedded in most EDA tools. Thus, we can regard either format as a set of Tcl procedure definitions rather than a new, unique language. In particular, both formats provide a way to describe:

• Voltage domains, or blocks operating at different voltages that require level shifters on all domain crossings
• Power domains, or blocks with a separate power supply that can be turned off
• Multiple supply nets with differing names and connections; in this type of design, there’s no longer any single global power connection
• Isolation logic, placed at the outputs of power domains where there’s a crossing to logic, which may remain powered on
• Retention registers, which are flip-flops within a power domain that have an “always-on” supply connection to retain state when the domain is shut off
• Always-on cells and paths for logic in a power domain (besides retention registers), which must remain powered on when the block that contains them is powered off
• Power switches, which are large on-chip switching transistors to shut off the power to a power domain.

Except for a few very minor points, any design that uses these features can be completely represented in either CPF or UPF. However, the syntax of a CPF representation will be completely different from that of a UPF representation. Each file would have a number of commands, and options to each command, to capture the power intent.

In a few cases, there’s a one-to-one correspondence between a CPF command option and a UPF command option. But, in general, the bits of information about the power intent “hang differently” from the CPF commands and the UPF commands. One piece of the designer’s intent may be represented in two commands with three options in CPF, but it also may be represented in three commands with two options in UPF.

FORMAT DIFFERENCES
The primary difference between the formats is that UPF doesn’t contain any commands to define library elements such as a level shifter or retention register. In both formats, you can require a particular library cell to be used in a certain situation. For example, you can require a specific level shifter to be used on all crossings between two specific domains. UPF doesn’t give you any syntax to define the level-shifter cell, its supply pin names, and its data pin names, though. CPF does provide syntax to define these library attributes.

In UPF, it’s assumed that some other library format exists, such as Liberty (“ Synopsys dot lib”), to capture this information. The Liberty 2006.6 standard contains some features for this, but the more recent 2007.3 version contains enough information to model level shifters and always-on cells and pins. It’s not yet clear how many library providers have created libraries based on this standard, but the required fields are there.

Continue on Page 2

The similarities show that the creators of CPF and UPF were thinking about a very similar scope. Yet at least one large area in CPF lies outside the scope of UPF, and one large area in UPF seems to be outside the scope of CPF. In these areas, it’s not possible to capture the same intent in each format, because there are no commands even vaguely equivalent in the other format.

One complex problem in multivoltage design is performing timing analysis at the different possible temperature and process corners and ensuring coverage of every different voltage scenario. CPF provides some commands that associate different library files and operating conditions with different power modes. Thus, a static timing-analysis tool could automatically sequence a number of different runs, one for each power mode, and make sure to associate the proper set of .lib files with each separate voltage domain. Yet UPF doesn’t provide any specific syntax for this scenario.

Another complex problem in multivoltage design is providing the right simulation semantics for data corruption and voltage resolution. When a block powers off, the non-retained net values should be set to X in simulation. However, different retention registers may have different constraints on the control signal input patterns to ensure correct retention. UPF provides some commands and options to ensure that simulators will check the control signals to retention registers and generate assertion errors or X values if the wrong sequence occurs.

UPF also defines a voltage-resolution package. A certain module may operate correctly if its inputs are in a certain voltage range, but may operate incorrectly and force unknown outputs if the inputs leave this voltage range. Also, a few extra command options could easily address some minor representational differences between the formats. These differences are unlikely to arise in many designs.

For instance, the CPF power switch library command provides an easy way to specify a “partly on” state for the power switch with two enable inputs, as well as specify current limits and other parameters. It may be possible to represent the same behavior in UPF and Liberty, but it’s unlikely that synthesis tools would be able to infer the correct control behavior from the UPF and Liberty descriptions.

EXAMPLES
Following are four complete examples focusing on different areas of low-power design. Each offers a simple design description and then the complete CPF and UPF files to capture the low-power intent. The discussion for each example compares and contrasts the way the intent is captured in each format. In general, you will see that both formats capture the intent, but the exact command structure is quite different.

Example 1: Two Voltage Domains
The first example design has one instance “u1” that operates at 1.2 V while the rest of the design operates at 1.0 V. Level shifters are required at each domain crossing. Code list 1 and Code list 2 show the CPF and UPF, respectively, for the design.

In section 1 of the files, you can see a one-to-one correspondence between the syntax elements. In CPF, the base command is “create_power_domain -name X -instances Y Z.” In UPF, the corresponding command is “create_power_domain X -elements Y Z.” This is the only instance where the two formats have the exact same command name. For a simple domain, this section may be all that’s defined by the initial RTL designer. Other extra options allow the designer to include or exclude certain pins of the blocks.

In section 2, we assign the voltages to the domains. This is required to select the proper level-shifter cells. The different formats have multiple ways of arranging the objects, as shown by the difference in commands. In CPF, we create a power net and associate it with a domain. In general, the “create_...” commands may be used early in the design process. Additional information can be added later using the “update_...” commands.

In UPF, we set voltages on ports and give them several possible power states. In this simple example, we define only one power state named “default” and specify the voltage for that state. Then we associate the ports as primary power nets for the appropriate domains.

Both CPF and UPF use the idea of a “rule” for assigning level shifters. Suppose a design has three domains at two different voltages. There will be several crossings with different domain names, but with the same voltage values on each side. One rule can be defined for each unique crossing voltage value, which reduces the amount of data that needs to be defined.

In CPF, the “-from” and “-to” options define the valid domains for the rule. In UPF, only one domain is specified at a time. Therefore, “applies_to inputs” is roughly equivalent to “-to” and “-applies_to outputs” is roughly equivalent to “-from.”

Continue on Page 3

It’s possible, but unlikely, that the initial RTL designer may wish to specify library cells by name for the various domain crossings. The RTL designer may rely on the physical design team, or in the future possibly rely on the synthesis tool, to select the appropriate cells. Nonetheless, special cases will arise in which some design team wishes to call out specific cells for the crossings. Both formats support this, as shown in section 4. The rules, as named in section 3, can be further expanded to specify cell names.

As noted earlier, UPF doesn’t provide any syntax to describe the pin names and function of the level shifter. In CPF, the “define_...” commands are used. Section 5 of the CPF shows how the level shifters would be specified.

Example 2: Simple Power Domain
The second example design has one instance “u1” that can be powered down. Several outputs must be clamped to zero when powered down, but one output “zn” must be clamped to one instead. The signal “iso” activates the isolation logic. Code list 3 and Code list 4 show the CPF and UPF, respectively, for the design.

Section 1 is the same as the voltage domain example above. Section 2 shows the syntax for declaring clamp values. Both formats use a rule to “hang” this information so that later on, additional information can be “hung” from the same rule.

For CPF, the general information about the rule uses “-from domain.” For UPF, the same information is declared with “-domain domain -applies_to outputs.” Input side isolation would be declared similarly, with “-to” in CPF and “-applies_to inputs” in UPF. In both formats, a “default value” for clamp outputs can be defined, either by using a wildcard “*” (CPF) or by defining no elements (UPF). Exceptions such as zn are declared using a second rule that names the specific port(s) with a different clamp value.

Section 3 shows the syntax for declaring the isolation signal. In CPF, this is done with the same command. In UPF, the additional information is “hung” on the same rule with a later command. Both formats allow an expression to be used for the isolation signal.

Section 4 shows the syntax for declaring the required location in the design hierarchy for isolation gates. In some designs, the location of the isolation logic must be fixed. Most often, the isolation logic may be required to be in the powereddown (source) domain or the destination domain. Both formats use a “-location” flag for this, but the names of the legal values are different. CPF uses “from” and “to,” while UPF uses “self ” and “fanout.”

Example 3: Retention Registers
This design illustrates several typical scenarios for retention registers. It has two power domains (Fig. 1). All of the registers in the first power domain, U1, must have retention. In the second power domain, U2, only registers in the sub-module U3 must have retention.

Retention registers come in at least two styles: “one-pin” registers with only a sleep pin, and “two-pin” registers with a separate save and restore pin. In this case, registers in U1 require save and restore controls, while registers in U2.U3 require a sleep control. Code list 5 and Code list 6 show the CPF and UPF, respectively, for the design. (Both skip the syntax already introduced.)

The concepts are very similar between CPF and UPF, but the distribution of the information differs slightly. For CPF, section 1, 2 shows that one command defines both the instances to be retained as well as the control net names. For UPF, the same concepts are split between two commands. In both formats, a “one-pin” retention control is specified by giving the same name for the save and restore nets. CPF allows active high or active low signals, while UPF also allows specification of edges.

Section 3 shows that both formats have a command to optionally map the retention requirements to specific cells or cell types. Future synthesis libraries may contain enough information to do this mapping. For now, though, the information can be defined using these formats.

Section 4 shows the CPF syntax to define the retention register. A retention register generally has two power-supply pins. One is for the retention operation, while the other is switchable.

Continue on Page 4

Example 4: Power Switches
This design illustrates several typical scenarios for power switches (Fig. 2). The design features three power domains. The first has a switched power net VDD1 that uses a header switch. The second contains a switched ground net GND2 with a footer switch. The third has an off-chip switched power net VDD3.

In general, a switched supply needs three bits of design information: (a) the “parent” supply, which is the input to the power switch; (b) the “child” supply, which is the output of the power switch; and (c) the enable signal. For externally switched supplies, (a) is not visible, but (b) and (c) are still required.

These three bits “hang” in different places in the two formats. Each bit of design information has a corresponding bit of library information. We need to know the supply input, supply output, and enable pin(s) of the power switch cells. Code list 7 and Code list 8 show the CPF and UPF, respectively, for the design. (Both skip the syntax already introduced.)

Section 1 is very similar for the two formats. CPF requires you to specify whether a net is power or ground. It also provides the opportunity to specify an external enable.

CPF clearly separates the three bits of information using different commands. Some of the information “hangs” directly from the domain object, and some is associated with a “rule” object. The create...rule commands define a rule, and the update... rule commands add further information to the rule. The parent supply net is associated with the rule in section 2, and the enable is associated with the rule in section 4.

The supplies aren’t associated using the rule, though. They are associated on the domain instead. The “internal” supply net is the one that’s connected to the standard power and ground pins of the standard cells. In some cases, this is an always-on supply. Sometimes it’s a locally switched supply or an externally switched supply.

For UPF, the example shows how two of the design’s bits of information, as well as some of the bits for the library data, are all captured together. Section 4 is very similar to the CPF section 4 with different terminology. UPF calls these nets “primary” supply nets, while CPF calls them “internal” supply nets.

Section 2, 4 shows the main UPF power switch command. The three “...port” options associate an instance pin name with a design net name. Therefore, “-output_ supply_port {VO VDD1}” means that the instance pin VO is the output or “child” supply and is connected to design net “VDD1.” The control port(s) and input supply port(s) are done the same way.

UPF provides simulation modeling for “on” states, “off ” states, “partial on” states, and “error” states. The simplest power switch has one control pin, and the switch is either on or off. However, a more complex switch may have multiple control pins. Each of the Boolean combinations of input values then can result in the switch being on, off, or partly on, or it may represent an illegal input pattern. In UPF, these are represented with named “states.”

Without going into more detail, the -on_state option here defines a state just named “on,” in which the input supply pin VI is connected to the output supply pin. The Boolean function of control pins under which this connection happens is “EN.” In terms of library pins, this command says VI drives onto VO when EN is high. In terms of design nets, this command says VDD drives onto VDD1 when en1 is high.

Section 3 defines the library cell for the power switches. There’s no specific syntax for this in UPF. Although the pin names of the library cell are implied by the pin names in the power switch command, there’s no opportunity to specify the name of the library cell. CPF requires you to specify whether the cell is a header or footer. It also provides for power switches that are “partly on,” with a stage 1 enable and stage 2 enable. However, the function is fixed, and the user doesn’t have the opportunity to specify Boolean expressions for the different states.

THE FUTURE
The IEEE will complete and ratify P1801 over the next year. Also, Cadence will continue to promote CPF while the other major EDA vendors favor UPF. Still, a growing number of EDA vendors and design companies will likely use both. Something similar has happened with RTL design languages.

Almost all EDA vendors and design companies use both Verilog and VHDL. In some cases, a smaller company may be able to focus on a single RTL language. Most multinational companies that practice design reuse, however, wind up with designs that are partly in VHDL and partly in Verilog. Look for the same situation to occur with CPF and UPF. Thus, EDA vendors risk losing market share if they ignore one of the formats.

Continue on Page 5

One area in which both formats need to improve is the handling of embedded IP. A design team or third-party company will often provide RTL for a block that can be integrated into a system-on-achip (SoC) design. In this case, there may be a number of options for low-power design in the IP, but the IP provider will want to limit the options to ensure that the IP will function correctly.

For example, an IP block may be constructed with several power-supply inputs, all connected to a single always-on supply. But if several voltages or several powerdown sequences are desired, the IP provider needs to constrain the possibilities. Neither CPF nor UPF provides a clean way to do this today. For UPF, the P1801 committee is actively discussing improvements, and Cadence may be internally considering improvements as well.

CPF and UPF cover 90% of the same concepts using completely different syntax. For voltage domains, power domains, retention cells, and other common lowpower design styles, low-power designers can represent their intent in either format. Yet there are several areas of difference between the formats. Notably, UPF requires Liberty to define library cells such as level shifters. In the next year, there won’t be any “convergence” onto a single power format. But designers can constructively use both formats to get their chips taped out.