Design Articles

Open UPF/IEEEp1801 Standard Roadmap Offers Technical and Business Advantages for Next Generation Power-Managed SoC Design

The Unified Power Format (UPF) is a power intent specification format championed by Synopsys, Mentor Graphics and Magma; it is the main contender to the Common Power Format (CPF) backed by Cadence. Both formats have a wide range of backers in the semiconductor industry, and both take direct aim at the low-power design problem. This article explains the UPF approach and how it’s implemented.

By John Biggs, ARM Ltd; Gary Delp, Silver Loon Systems; Steve Bailey, Mentor Graphics; Kevin Kranen, Synopsys; Rolf Lagerquist, Texas Instruments; Minh Chau, Texas Instruments

The global energy and climate crises that have gained significant awareness over the past six to eight years have “fueled” the emergence of so-called “green” technology initiatives in several key markets, most notably the information technology sector. Semiconductor component power consumption represents problematic challenges that include: mega-server farms consuming hundreds of megawatts, handheld consumer devices, and physical device scaling below 45nm semiconductor process nodes. The result has been a newfound awareness that “off-by-default” may become the mantra for next-generation semiconductor design practice.

UPF logo

In the realm of semiconductor design, “off-by-default” gives rise to the notion that if a sub-module on a System-on-Chip (SoC) component is not actively processing data, then the sub-module should be “switched-off” with respect to the SoC’s power grid.  For “high end” Power-Managed SoCs (PM-SoCs), the “off-by-default” engineering task translates into the creation of hundreds of power domains and an array of specialized and heretofore, unknown and unexplored power savings techniques.

The power-savings efforts used by chip designers have a single-degree of freedom with respect to the IP core re-use that dominates the architectural design process for SoCs.  It is not uncommon to find that 90% of an SoC may be the product of IP re-use.  IP cores are integrated across a broad spectrum of components in various application markets characterized by performance, function, and in the context of this article, power requirements.  The increasing power complexity associated with PM-SoCs has served as a wakeup call to the industry and created a desire for standardized power-intent specification formats such as the Unified Power Format (UPF) and the Common Power Format (CPF).

When specifying power-intent for a PM-SoC, semiconductor design and verification teams recognize the value of a power-intent specification side file that is processed in conjunction with the PM-SoC’s RTL specification.  Power-management and power-intent acutely affects every phase of the SoC design and manufacturing cycle.  There exists no manufacturing proxy for the complexity of semiconductor design and no current or past EDA proxy for the pervasive methodology impact that has been created by power-intent specification.  Component manufacturers are keenly aware that their design team’s EDA methodology flows are defined by a few major EDA suppliers.  It is this methodology impact from power-management’s pervasiveness that screams so loudly to the industry for a standardized power-intent format specification.

The EDA industry’s success along the semiconductor technology trajectory has been defined by innovation and cooperation between EDA suppliers and component manufacturers.  Chip companies demand interoperability across key interfaces along the value chain from their EDA suppliers, thereby allowing an amalgam of EDA software customized to their company’s needs. 

Current 45, 32, and 22nm EDA methodology flows are at the “raw material” stage for overall SoC R&D costs that now exceed $25M per component.  Component companies must consider the business risks associated with adopting “proprietary technology standards” that lack broad EDA industry acceptance.  Becoming “locked-in” to a single chip-design reference flow that relies upon non-open, “controlled” specifications from one EDA company presents an unnecessary business and engineering risk for chip executives and managers.

The semiconductor industry’s leading component manufacturers, in cooperation with Accellera, initiated an open standardization effort for power-intent that resulted in the Unified Power Format (UPF) 1.0 standard.  Since the Accellera UPF 1.0 standard was approved, the IEEE approved a standards committee to develop the P1801 (UPF 2.0) power-intent standard as an evolution of the Accellera UPF 1.0 standard.

An important aspect of any power-intent format standardization is reflected in the full participation by a broad spectrum of companies within the semiconductor industry.  In this sense, the UPF standard has received the support of three of the four major EDA vendors:  Synopsys, Mentor Graphics, and Magma Design Automation.  As important as EDA-vendor endorsement is to an EDA standard, the acceptance of the standard by the engineering design community defines the standard’s validity, quality, and longevity.  As of the printing of this article and to the best knowledge of the UPF EDA endorsers, approximately 70 percent of the major semiconductor companies have plans to adopt UPF into their component design flows.  From the semiconductor foundry perspective, TSMC, the Common Platform (IBM, Samsung, & Chartered), and UMC all have proven UPF 1.0 foundry flows in place today.

The UPF 1.0 standard has provided a strong technical base for power-intent specification using a power-domain-centric syntax for isolation, level-shifting, and retention policies.  The power-intent flexibility afforded by UPF’s abstraction and definition for power domain scope and extent provides a concise semantic for design-element partitioning within a complex logical hierarchy.

Figures 1, 2, and 3 illustrate a progression of power-domain element inclusion with respect to a power domain’s scope and extent for the associated UPF code segments in the respective figures.  The concept of contiguous versus non-contiguous power domains is presented.  UPF command files upf_a, upf_b, and upf_c are applied in subsequent figures with increasing power-domain complexity. The example walks through the process a designer may follow while imposing a power-aware architecture upon a legacy SoC sub-system. The example consists of:  an embedded processor core (UP), a DMA engine (DMA), a MAC (MAC) with transmit (XMT) and receive (RCV) instances, and a receive buffer memory (BFR).

The power-aware design constraints may be coarsely defined to reduce the SoC power by applying Power Shut-Off (PSO) to the communication sub-system, MAC. In Figure 1, upf_a sets the scope at design element UP for the creation of the “Top” power domain.  The second set_scope command drops the scope one level down in the logical hierarchy to design element MAC, allowing the second create_power_domain statement to create PD_1.  PD_1’s create_power_domain statement only requires a –include_scope option to capture all of the elements identified in the comments of line 4. 

figure 1
Figure 1

Design elements UP and DMA remain in the “Top” power domain.  The create_supply_net and create_supply_port will be used to create explicit supply nets and ports at logical hierarchy level UP, while implicit supply ports and nets will be created within the logical hierarchy for the elements (MAC, RCV, XMT, and BFR) in PD_1’s extent. At this point the new power analysis mayt have reduced the power by 20%, but it is not yet optimal.

In the next refinement the designer recognizes that the transmit module, XMT, should be “on” under different circumstances than the MAC’s receiver.  In addition, the DMA’s data transmission closely correlates to the MAC’s XMT function, justifying identical power management for the DMA and XMT instances.  Therefore, Figure 2, upf_b incrementally adds one set_scope and one create_power_domain command to upf_a to create power domain PD_2.  upf_b elevates the scope one hierarchical level with the third set_scope command, thereby capturing element UP/DMA for inclusion in PD_2, along with extracting element UP/MAC/XMT from PD_1 with the –elements parameter. 

figure 2
Figure 2

Design element UP remains in the “Top” power domain.  The create_supply_net and create_supply_port commands should be used to create explicit supply nets and ports at logical hierarchical level UP.  Implicit supply port connections will then be created for PD_2 within the logical hierarchy to allow supply net connections between elements DMA and XMT.  PD_2’s non-contiguous property requires that implicit supply port connections will pass through PD_1’s logical hierarchy. After power analysis, the designer realizes an additional 10% original power savings.

The final designer refinement recognizes that the memory buffer can be powered off whenever the UP is powered down. Then Figure 3 incrementally builds upon upf_b (upf_c) with one final create_power_domain statement to create a two element, non-contiguous power domain, PD_3.  The application of upf_c extracts element UP/MAC/BFR from PD_1 with the –elements parameter, while also encapsulating the top element A in the logical hierarchy with the combined use of the –include_scope parameter.  

The “Top” power domain no longer has any design elements.  While explicitly creating supply nets and ports, as with PD_1 and PD_2, an additional set of implicit supply port connections will now be introduced for PD_3 into the logical hierarchy for PD_1. .  This final power optimization analysis shows an additional 10% original power reduction.

figure 3
Figure 3

In the final analysis, the designer was able to reduce the original SoC sub-system power by 40% through incremental application of UPF constraints without requiring RTL modifications to the legacy design IP.  It should be apparent from the above example that by utilizing a UPF power-intent side file in conjunction with the UP SoC IP RTL, the UP IP may be readily ported to additional SoC target markets that may have differing power requirements.

The current and future importance of IP re-use and SoC integration provided an impetus for the UPF 1.0 creators to pay particular interest in the separation of power-intent specification and implementation.  By allowing IP cores to carry separate UPF power-intent implementations, design architects can specify power-intent early in the chip-architecture phase.

While UPF 1.0 provides an adequate set of power-intent semantics, the IEEE P1801 (UPF 2.0) standard extends the power-intent command set for simulation modelling through the load_simstate_behavior and the set_simstate_behavior commands.  Simulation behaviour for low-Vdd-standby can be effectively modelled using UPF 2.0’s extended definitions for supply levels as defined by the PARTIAL_ON, UNDETERMINED, FULL_ON, or OFF semantics.  New power-state definitions have been introduced to define simstates for supply sets such as: CORRUPT_ON_ACTIVITY, CORRUPT_STATE_ON_ACTIVITY, and CORRUPT_STATE_ON_CHANGE, thereby providing increased accuracy in RTL power-aware simulation behavior.

UPF’s command layering, or refinement semantics, allows IP providers to specify the “what” part of power-intent abstractions without worrying about implementation-specific details.  UPF command layering enables a reusable, technology-independent UPF specification for vertical market applications of generalized IP cores.  The IP user/implementer can provide additional refinement specifications, e.g. use_interface_cell, describing the ‘how’ of the power-intent specification by targeting specific power-management architectures or technology libraries.

UPF 2.0 extends UPF 1.0’s abstractions and refinement capability by adding the concept of supply sets.  The power-intent refinement capability has been enhanced with predefined or placeholder supply set handles.  By using supply sets, supply nets can be aggregated into predefined primary, supply, default_retention, and default_isolation power rails.  An association command, associate_supply_set provides syntactic indirection for supply set references.  Additional power-rail references can be made for predefined supply set functions such as power, ground, pwell, or nwell designations.  Customized supply net functions can also be defined.  The supply set abstractions in UPF 2.0 define a base functionality for implicit and automatic connection semantics for complex power-intent hierarchies.

Consider the following implementation/refinement scenarios:

  1. UPF Constraints

IP provider needs to identify what is to be isolated without prescribing how:

set_isolation my_iso -domain my_pd \
-clamp 0

  1. UPF Configuration

System level simulation needs to configure the logical power control without having to specify the power supplies:

set_isolation my_iso -domain my_pd \
-isolation_signal CLAMP \
-isolation_sense  high

  1. UPF Implementation

Finally, the details of the power supplies are added during implementation:
set_isolation my_iso -domain my_pd \
-isolation_power_net VDDG \
-location parent

If there is no need for successive refinement, everything can be specified at once:

set_isolation my_iso -domain my_pd \
-clamp 0 \
-isolation_signal CLAMP \
-isolation_sense high \
-isolation_power_net VDDG \
-location parent

UPF 2.0 provides for a new command, set_port_attributes, to allow specific power-relevant information to be assigned to power domain ports. Port attributes, such as clamp levels, allow IP providers to control any aspect of a port’s power intent.  Further port power-intent refinement is achieved by adding control attributes for related supply sets.  EDA tools may use power-intent port attributes for corruption semantics and buffering choices for special-exception nets.  Certain UPF properties can also be annotated directly in HDL source code descriptions using UPF 2.0’s command alternative syntax.

The forthcoming UPF 2.0 standard, also introduces forty (40) new query commands that can serve as the basis for extensive and interoperable power-intent analysis.  With a refined error-handling definition, the TCL-based syntax for UPF 2.0 completes a well vetted open-standard power-intent specification.

It’s true that open standards do not come to closure overnight and require painstaking, collaborative efforts between suppliers and end users.  However, in the end, open standards provide a superior end product for interoperability that is the result of input, refinement, and content from many minds and salient interests.  From this vantage point, we believe that market forces will soon converge upon a single power-intent format, the Unified Power Format. 

Twentieth century feminist, Shulamith Firestone, warned that “...power, however it has evolved, whatever its origins, will not be given up without a struggle.”  While Ms. Firestone didn’t have semiconductor design on her mind when she spoke these words, the Unified Power Format has given 21st century design managers and engineering teams a renewed comfort in the inevitable power struggle with 32 and 22nm process nodes.  The UPF 1.0 and IEEE P1801 (UPF 2.0) standards (Table 1) have been vetted through an open standardization process involving the top EDA and semiconductor suppliers in the industry, thereby laying a foundation to address the challenges of power management in the years to come.

Table 1: UPF 1.0/IEEE P1801 (UPF 2.0) Command Comparisons
(excluding UPF 2.0 query commands)
** UPF 2.0 includes all UPF 1.0 commands except (#) **

UPF 1.0

IEEE P1801 (UPF 2.0)

























get_supply_net (#)








































ARM Inc.
Sunnyvale, CA
(408) 734 5600

Mentor Graphics Corporation
Wilsonville, OR
(503) 685-7000

Silver Loon Systems LLC
Rochester, MN
(507) 289-7276

Synopsys, Inc.
Mountain View, CA
(650) 584-5000

Texas Instruments Inc.
Dallas, TX
(800) 336-5236

This article first appeared in the October/November issue of Portable Design. Reprinted with permission.

Digg Reddit Stumble Upon Facebook Twitter Google BlinkList Technorati Mixx Windows Live Bookmark MySpace Yahoo Bookmarks Diigo

Insert your comment

Author Name(required):

Author Web Site:

Author email address(required):


Please Introduce Secure Code: