The Many Flavors Of UPF: Which Is Right For Your Design?

Energy efficient electronic systems require sophisticated power management architectures that present difficult low-power verification challenges. Accellera introduced the Unified Power Format (UPF) standard in 2007 to help engineers deal with these complex issues.

To keep pace with the growing complexity of low-power designs, the UPF standard has itself continued to evolve through the release of five versions, the most recent being in 2018, UPF 3.1. Of course each new release adds more capabilities as well as fixes to previous versions, and UPF 3.1 added several new features and improved the clarity of existing features.

However there are still valid reasons for either choosing or having to use earlier versions of the standard. For example, when legacy IP you are reusing has been designed using an older UPF version, so you have to stick with that. Or one IP component was built using a different UPF standard than other IP in the same design. On the other hand, if you are building on top of an existing design, there could be some functionality that requires you to move to a newer UPF standard. As well, some verification tools support different standards by default. Adding to the problem, the different UPF standards are not necessarily backward compatible, so if you are moving from one standard to another or from different verification tools having different defaults, the design can potentially fail to work.

Because of these and other considerations, low-power designers need to decide which is the right UPF standard for their design. And when moving from an earlier to a later standard, it is important to understand the compatibility, differences, and challenges related to migration from one version to another and the impacts on verification. For SoC designers, the obvious question is which UPF version should they use for the whole design if the IP in design have been verified with a different UPF version.

To help answer these consequential questions, we will highlight the semantic differences between the last four versions of UPF (from UPF 2.0 onward). We will also describe migration challenges when going from one UPF version to another and provide guidelines to avoid these challenges.

Semantics: When “Is” doesn’t mean “Is”

With every new version of the UPF standard, new commands are introduced and a number of semantics or concepts are clarified. Most of the time these clarifications are not aligned and are not backward compatible. Thus, as all semantic clarifications are meant to address the problems or gaps in previous standards, as a general practice it is important to follow the latest semantic.

One common challenge is when the existing design is built upon the semantics definitions of a previous standard and the design gets migrated to a new standard resulting in a failure. Another common scenario is that when an IP built using an older semantics is integrated into an SoC built using UPF 3.1, the whole system may fail to work. Even though upf_version can be used to control the syntax of subsequent UPF commands, a common single semantic is applied to the whole design. This is because the verification tools follow a common semantic for low-power verification of the whole design.

A more serious problem arises when the semantic of a particular concept gets changed and it is not aligned with the designers understanding and intent. It becomes of utmost importance to know all the semantic differences and the reasons for the changes. Migrating to the latest standard may require editing the UPF files to resolve the semantic differences. Following are some of the concepts which have been changed in multiple UPF standard releases and the migration tips for these.

Power states

UPF defines two separate styles of capturing power state information: Power State Tables (PST) and Power States. Power states play a significant role in describing the power intent. If the power states are not defined properly, there will be significant consequences, as they are used for both verification and implementation of power management. Power state definitions define the simulation aspect of the various states the system goes into. The verification tools also use them for checking the power management structures; whereas implementation tools use them to insert the power management logic.

UPF 1.0 supported only PST, which allow the specification of power states in terms of supply nets/ports and their possible combinations of values. It is a tabular representation of the possible state combinations for the given supplies. The tabular representation makes it easier for users to comprehend the power state dependencies and possibilities. However, this tabular format has several limitations.

UPF 2.0
To overcome the shortcomings of the PST representation, UPF 2.0 introduced a completely new style of expressing power state information via the add_power_state command. This allows users to define power states on supply sets and power domains. The add_power_state command requires users to express power states in terms of Boolean expressions via –logic_expr and –supply_expr switches. Although this is very powerful in capturing more complex relationships including hierarchical dependencies, it has the potential of causing problems if not used properly. The absence of sufficient restrictions and guidelines in the LRM implies that tools cannot catch improper usage. The hierarchical composition capability is built right into the command itself and promises to reduce the state explosion. However, the lack of methodology and semantics has meant that users have been slow in adopting add_power_state for representing power states.

UPF 2.0 doesn’t define proper semantics about how the states are handled when supply sets are associated with other supply sets or handles. UPF 2.0 does not restrict the transfer of power states in the supply set associations. So the power states defined on one power domain may incorrectly affect some other power domains which are associated with the same supply set.

UPF 2.1
UPF 2.1 clarified a lot of semantics to enable greater adoption of the add_power_state command. The standard marked PSTs as legacy — implying that the command, although present in the standard, was present only for backward compatibility and was not recommended for future use. The LRM also clarified that supply set handles are local supply sets. Power states do not get transferred. Power states added to supply set handles are a property of supply set handles and not its associated supply set. It also added –supply, –domain, and –complete to the add_power_state command and another simstate, “CORRUPT_STATE_ON_ACTIVITY”. A number of restrictions have also been imposed on the add_power_state command to avoid the state explosion, unlimited possibilities of defining the power state expressions, in order to promote better methodology for power intent modeling.

UPF 2.1 failed to provide clear definitions about the relationship between the power states of various IP and how the system behaves a whole. The semantic also lacked any information about system-level power modeling and how much power a sub-system or whole system will consume when it is in a respective state. Further, the simulation behavior based on power state definitions relied on the loose concept of multiple power states being active at the same time and the most corrupt simstate being the active simstate driving the simulation.

UPF 3.0 / 3.1
UPF 3.0 introduced the new command create_power_state_group to create a group of related power states. A power state group is used to collect related power states defined by add_power_state. The legal power states of a power state group define the legal combinations of power states of other objects in this scope or in the descendant subtree. This can be used to define the power state of a whole system which relies on the power state definitions of its IP. It also allows verification tools to deduce the relation between the power domains and to drive static analysis.

UPF 3.0 overhauled the definitions and restrictions for power states, providing clear semantics. This allowed writing power state expressions in a more definitive manner and solved the problem related to power states being too flexible. In addition to many other concepts that were introduced into the new standard, UPF 3.0 introduced three new objects on which power states can be applied; specifically group, model, and instance. It also introduced the option [-power_expr {power_expression}] to facilitate the calculation of power consumed when the IP is in that particular power state.

However, there could be backward compatibility issues when migrating to the latest semantics for power state. The user may have to modify power state definitions if they are not complying with the restrictions. Some of the complexities could be avoided if the power states are already definitive in nature and there isn’t any overlapping between fundamental states.

Port versus Path based semantics

Whenever source logic goes OFF and sink logic in an ON state, there is a need for isolation. UPF provides a set_isolation command to specify how and where the isolation cell gets inserted. If the isolation is not inserted properly at the right path, then it can lead to a functional failure. If the isolation is placed at a location where it is not required, it is a redundant cell and wastes area and power.

UPF 3.0
UPF 3.0 adds the option –source and –sink to the set_isolation command. These options allow users to avoid specifying the complete port list. Isolation is applied on all the matching ports which meet the criteria. The UPF 3.0 -location option specifies where the isolation cell gets placed.

Consider the scenario shown in the schematic.

The UPF command, set_isolation iso3 –domain red –location parent, specifies the path where the isolation needs to be applied and the domain at which the cell needs to be inserted. However the semantics are not clear as to which port the cell will be inserted. Thus some verification tools may place the iso3 cell at the highconn of out1 port; this results in collateral damage as the path from out1 to in4 also gets isolated, which is not required.

UPF 3.1
First, UPF 3.1 clarified that isolation strategies are applied on a per path basis in the design. It introduced the concept of net splitting, where a net can split to minimize collateral damage. If -location fanout is specified, the target insertion port is the port on the location domain boundary that is closest to the receiving logic. If -location fanout is not specified, then the target insertion port is the port of the location domain that is (for the self domain) or corresponds to (for the parent or child domain) the port to which the strategy applies. In the case of multiple paths to different receiving supplies, care should be taken when specifying the location domain, as an isolation cell inferred for one path may affect another path. It will be an error if the isolation power intent cannot be implemented without duplicating ports.

This being more of a semantic clarification, most of the time this should not cause any functional failures when migrating to UPF 3.1. In some cases, the user may need to update or write additional set_isolation commands to insert the cells of the paths which were isolated earlier.

UPF attributes

UPF supports the specification of certain properties of objects in a design. These attributes provide information that supports or affects the meaning of related UPF commands. Such attributes can also be defined with HDL attribute specifications in design code or with Liberty attribute specifications in a Liberty model. Since there are more than one source where the same attribute information can come from, there needs to be a clear set of restrictions and priorities to avoid conflict.

UPF 2.1
The UPF 2.1 standard did not provide a mechanism to set precedence rules in order to avoid conflicts.

UPF 3.0
UPF 3.0 clarified the precedence of attributes by defining how the HDL and Liberty attributes are interpreted. The attributes specified in HDL code or Liberty models are treated as if they were implicitly specified using the UPF command set_port_attributes -model -ports (for port attributes) or the UPF command set_design_attributes -models (for design attributes).

The UPF 3.0 standard also introduced the concept of characteristics attributes, which represent characteristics of a module or cell that apply universally to all instances of that module or cell. Designers can rely on verification tools to error out in the cases when this constraint information is not met. Some of the predefined attributes are always characteristics attributes. In addition, any attribute specified either explicitly or implicitly with set_port_attributes -model or set_design_attributes -models is a characteristic attribute. Non-characteristic attributes are can be overridden, as specified by the precedence rules for attribute specifications. Characteristic attributes cannot be overridden.

UPF 3.1
The new UPF 3.1 standard removes any ambiguities in the definitions and restrictions of attributes. The characteristics attributes were replaced with clearer definitions as to which attributes are model specific only, which are instance specific only, and which can be applied at both the model and instance levels. The constraint information is also made clear in terms of the error defined. For attributes that can be model-based specified only, there will be an error if they are instance-based specified, and vice-versa.

In certain cases the attribute specification can lead to an error when the design is migrated to the new standard. This suggests potential problems in the design, a conflict in the information coming from Liberty and UPF. This will require editing the UPF file and making sure that the right set of information is specified in the power-intent.

Conclusion

There is no single answer to the question “which is the right standard for my design?” However with a clear understanding of the syntax and semantic changes over the UPF releases, designers will have a better judgment of the UPF version for their respective design.

These guidelines will come in handy when you aren’t sure which flavor of UPF you want on any given design:

• Use the UPF command upf_version to specify the syntax of commands used further in the UPF file. It makes sense to specify this command per a UPF file if the file has a different syntax from the parent UPF file from which it got loaded.
• Check the default UPF standard supported by your verification tool with respect to semantics. Many low-power verification tools default to a standard and provide tool options or attributes to control a specific functionality.
• Unless absolutely necessary always follow the latest semantic.
• If starting-off with a new design, follow the same UPF version for all the design and UPF files. Usually the semantic cannot be controlled for a particular part of a design, however, it is applicable for the whole design.