by Erich Marschner, Product Manager, Questa Power Aware Simulation, Mentor Graphics
Usage of the Unified Power Format (UPF) is growing rapidly as low power design and verification becomes increasingly necessary. In parallel, the UPF standard has continued to evolve. A previous article1 described and compared the initial UPF standard, defined by Accellera, and the more recent IEEE 1801-2009 UPF standard, also known as UPF 2.0. The IEEE definition of UPF is the current version of the standard, at least for now, but that is about to change. The next version, UPF 2.1, is scheduled for review by the IEEE Standards Review Committee in early March. When it is approved, UPF 2.1 will become the current version of the UPF standard.
UPF 2.1 is an incremental update of UPF 2.0, not a major revision. That said, UPF 2.1 contains a large number of small changes, ranging from subtle refinements of existing commands to improve usability, to new concepts that help ensure accurate modeling of power management effects. This article describes some of the more interesting enhancements and refinements coming soon in UPF 2.1.
One of the most significant aspects of UPF 2.1 is the fact that it represents a major step forward towards a unified low power format that is supported by all EDA vendors. For some time, UPF and CPF, the Common Power Format from Si2 and Cadence, have co-existed as alternative low power formats. While similar in many ways, the two formats have been different enough to make automatic translation between them difficult, which in turn has created problems for users who have a multi-vendor flow that requires use of both formats. Because of this, many low power designers and verification engineers have been pushing for unification of the two formats into a single format that all tools would support.
Si2 took some steps in that direction several years ago, by adding certain features of UPF into the most recent version of CPF, but this did not really address the interoperability issue well enough. More recently, the IEEE P1801 UPF working group has been working to include some aspects of CPF in the next version of UPF. To enable these additions, Si2 and Cadence both joined the IEEE P1801 UPF working group in early 2011, Si2 donated the definition of CPF 2.0 to the working group, and Cadence has actively contributed to the development of UPF 2.1. As a result, UPF 2.1 includes some new features derived from CPF concepts. These features appear to be sufficient to enable CPF users to move to a UPF-based low power flow. IEEE P1801 working group members who use both formats have strongly supported the integration of CPF features into the next version of IEEE standard 1801 UPF.
POWER MANAGEMENT CELL DEFINITION
The primary CPF-inspired new feature in UPF 2.1 is a set of commands for defining power management cells such as isolation, level-shifting, and retention cells. These new commands enable users to provide a complete power intent specification in UPF, without relying on Liberty libraries for the definition of power management cells. Some users require such commands because their Liberty libraries may be out of date or incorrect, and the cost of modifying and re-verifying the modified libraries is often prohibitive. With these new power management cell definition commands, power intent for a given design can be expressed without updating the Liberty libraries.
MACRO CELL MODELING
The other CPF-inspired new feature in UPF 2.1 is a set of commands for defining power intent for macro models. While not strictly necessary – macro models can be represented with existing UPF 2.0 features – these new commands provide additional convenience by packaging up the power intent for a given macro so that it can be easily applied to each instance of the macro. These commands -begin_power_model, end_power_model, and apply_ power_model – effectively provide a standardized UPF subroutine definition and invocation capability.
Other enhancements in UPF 2.1 also address macro cells. In particular, refinements to the definition of the boundary of a power domain now enable isolation and level shifting strategies to apply to ports of a macro cell instance. New predefined attributes UPF_feedthrough and UPF_unconnected have been added also, to provide information about the internals of a hard macro instance that are required during network analysis to determine driving and receiving supplies of a net.
Additional changes clarify how anonymous supply sets are constructed for ports of a hard macro based upon the related supplies associated with the port and the pg_types of those related supplies. These anonymous supply sets are considered by isolation and level shifting strategies written using -source or -sink filters, so they need to be welldefined to ensure that isolation and level shifting insertion works correctly.
UPF 1.0 defined supply nets; UPF 2.0 added the concept of supply sets, which are collections of related supply nets. Both are used to model the supply networks providing power to various portions of a design.
The supplies powering logic driving and receiving a signal affect power management requirements:
- If the driving supply can be off when the receiving supply is on, isolation is required.
- If the two supplies can operate at significantly different voltage levels, level shifting is required.
Because of this, isolation and level-shifting strategies often use the driving/receiving supply as a filter to determine where isolation or level shifting cells should be inserted.
The -source filter for supply S selects any port that is driven by logic powered by a supply that matches S. The -sink filter for supply S2 selects any port that is received by (i.e., fans out to) logic powered by a supply that matches S2. The sink filter in particular makes it easy to selectively isolate certain paths from a port while leaving other paths unisolated, or to isolate different paths with different controls or different isolation supplies. But what does it mean for one supply to "match" another? This is where the UPF 2.1 concept of supply equivalence comes in.
At the lowest level, two supply nets are equivalent if they are connected directly or indirectly, either by HDL statements or by UPF commands or by a combination of both. This is called "electrical equivalence" in UPF 2.1.
If two supply nets are electrically equivalent, then they are also functionally equivalent: they will both always have the same state and voltage. Two supply nets can be declared to be equivalent even if they are not connected in the design, in which case the equivalence declaration acts as a constraint on the eventual implementation or on use of an IP block in a larger system.
The equivalence concept also applies to supply sets. Two supply sets are considered equivalent if their corresponding required functions (the supply nets, or placeholders for supply nets, that make up each supply set) are all equivalent. Two supply sets are also considered equivalent if they are declared to be equivalent.
This definition of equivalence enables other UPF commands to function in intuitively natural ways. For example, the set_isolation command will by default use supply equivalence in determining which ports are to be isolated when set_isolation is specified with a –sink or –source filter. The command create_composite_domain will also consider supply equivalence when ensuring that all subdomains have the 'same' primary supply. In general, where UPF 2.0 required two supplies to be "the same", UPF 2.1 now requires them to be equivalent.
SUPPLY SET REFINEMENTS
Several other changes in UPF 2.1 also focus on supply sets and related concepts. For example, UPF 2.0 allows specification of attributes representing the driver supply or receiver supply of a port, in case the logic driving or receiving that port is not in the design (for a primary input or output) or not visible (for a hard macro instance). However, UPF 2.0 assumes that all ports have drivers or receivers, as appropriate; the possibility that a port is left undriven or is not connected to a sink is not considered. In UPF 2.1, this is modeled explicitly with the above-mentioned UPF_ unconnected attribute, and the semantics of supply sets and driver/receiver supply analysis account for this, even to the point of making different assumptions about primary ports, which are assumed to be connected externally, and ports of leaf-level instances, for which the same assumption may not hold.
UPF 2.1 also refines the definition of default supplies for isolation and level shifting cells inserted by strategies that do not explicitly identify the relevant supplies. For level shifters, the default supplies are now those of the logic driving the input side and the logic receiving the output side, respectively, provided that the domain crossing involved is not overly complex. For isolation, the default isolation supply now reflects the fact that the location in which an isolation cell is inserted typically determines what isolation supply will be used for that cell. UPF 2.1 also adds the concept of supply availability: which supplies are available in a given domain to power buffers inserted during implementation. This allows the user to constrain implementation tool decisions to avoid routing difficulties.
In UPF 2.0, buffers can be inserted at a given domain boundary port by associating a "repeater supply" attribute with that port. However, this attribute can only be associated with outputs of a domain, not with inputs; this limits its utility. In UPF 2.1, the repeater supply attribute has been replaced with a new strategy command, set_repeater, which supports much more flexible buffer insertion and functions consistently with other strategy commands for isolation and level shifter insertion.
The retention strategy command, set_retention, has also been improved in UPF 2.1. The initial definition for set_retention in UPF 1.0 was modeled on the use of a balloon latch to which a register's value could be saved before power down and from which the value could be restored after power up. UPF 2.0 added the –use_retention_as_primary option to reflect the fact that retention might be accomplished by just keeping the latch powered up. However, UPF 2.0 still requires both save and restore control signals even in this case. Also, the UPF 2.0 semantics for retention do not model very well some aspects of practical implementation methods, such as the "live slave" approach used with master-slave flipflops. In UPF 2.1, the semantics of set_retention have been adapted to allow for various types of retention, with various combinations of control signals, and the UPF 2.1 specification explains how each of these types is modeled in simulation.
The changes in UPF 2.1 described above are only some of the many refinements that have been made in the new version of UPF. If these changes strike you as minor and incremental, you would be partly right: the changes are indeed incremental, but the aggregate effect is quite significant. Many of these changes focus on improving the precision, accuracy, and fidelity of power intent expressed in UPF, to make the standard easier to use and to ensure that it intuitively captures the concepts and functionality we need to represent. Just as a high-resolution display represents the same images as a lower resolution display but with much finer detail, UPF 2.1 will enable users to model their power intent using familiar concepts but with much greater finesse. Ultimately, the enhanced modeling precision and accuracy provided by UPF 2.1 should translate to higher quality and productivity in design and verification of low power systems.
Although UPF 2.1 is close to final approval, the 16+ user and vendor organizations making up the IEEE P1801 UPF working group will continue driving the evolution of UPF to address new and evolving requirements for low power design and verification. In fact, the next phase of UPF standard development will most likely begin soon after UPF 2.1 is approved, starting with decisions about what issues to tackle next and collection of requirements in those areas. If you are interested in influencing and/or contributing to the further development of UPF, you can join the working group and take part in its regular meetings.2
UPF is supported today by many of Mentor Graphics' products, including Questa Power Aware Simulation (PASim), Olympus, Veloce, Tessent, and Calibre. If you are interested in how these tools support and make use of UPF power intent specifications, contact the corresponding product managers for more information.
- Marschner, E., "Evolution of UPF: Getting Better All the Time", Verification Horizons, Oct. 2012 Issue.
- For more information about the IEEE P1801 UPF working group, go to the P1801 web page at http://standards.ieee.org/develop/project/1801.html or contact the author at erich@ p1801.org.
Back to Top