Power Management And Integration Of IPs In SoCs: Part 1

IPs – whether in the form of soft or hard macros – are the epicenter of today’s SoC designs. Integration of IP with low power designs and conducting power aware (PA) verification are always complex and cumbersome. Because most of these IPs are self-contained, pre-verified at the block level, and must be preserved in their totality when integrated or verified at the SoC level.

Until UPF 3.0 (IEEE 1801-2015), the soft macro boundary was imprecise without terminal boundary concepts for ancestor power relations. Likewise, UPF 3.1 (IEEE 1801-2018) categorically explains the formation of an anonymous power domain around hard macros when it lies outside all the other power domains. Both of these new semantics are crucial for IP integration at the system level and for performing PA simulation (verification). Specifically, in the bottom up integration perspective, boundary conditions for these macros were not well defined until UPF 3.1 (IEEE 1801-2019). As a consequence, low power macro verification solutions were not always intuitive, portable, or standardized. This article (in a two-part series) addresses the soft macro power management challenges in SoC environments, based on the UPF 3.1 standard. Part two will do the same for hard macros.

Before diving deeper into the topic, it will be helpful to explain some terminology in UPF context.

UPF: The Unified Power Format (UPF) is the ultimate power reduction methodology for any design, its verification, and its implementation. UPF provides the concepts and artifacts of power management architecture, power aware verification methodologies, and low power implementation mechanisms. However, there are different versions of UPF available today:

• UPF 1.0 (UPF Accellera 2007)
• UPF 2.0 (IEEE 1801-2009)
• UPF 2.1 (IEEE 1801-2013)
• UPF 3.0 (IEEE 1801-2015)
• UPF 3.1 (IEEE 1801-2018)

It’s important to note that a new standard release does not totally make previous releases obsolete. As well, verification and implementation tools support different variations of UPF for different reasons.

Soft Macro: Soft macros are generally designed in synthesizable RTL and are usually part of a larger RTL subtree before implementation. A standalone, self-contained UPF is mandatory for implementation. This is necessary to accurately model the outside environment view of the macro, based on the internal power supplies, because, for soft macros, implementation is hierarchical but verification must use the full SoC flat view. The UPF accompanied with a soft macro must be complete within its entity; i.e. a self-contained UPF that will define its own top-level power domain with create_power_domain -elements {.} –is_atomic commands and be associated with the {UPF_is_soft_macro TRUE} attribute. The atomicity – i.e. the minimum extents of the said power domain – ensures that any instance within the power domain can never be sliced out and added into another power domain, as this will cause a UPF processing error.

Hard Macro: Hard macros are already synthesized and sometimes placed and routed design blocks. Their implementation does not usually utilize the UPF, even though they are power aware and contain isolation cells, power switches, and power states, etc. When delivered they are usually HDL behavioral models accompanied by Liberty libraries. Liberty defines only partial implementation of power architectures and interface characteristics, such as related supply on logic ports, pg pins, etc.  Hard macros are often silicon proven and come with a pre-defined UPF file, with both pre-verified at the IP (block) level. However, in the UPF perspective, a hard macro is an IP block instantiated in the design with the UPF HDL attribute {UPF_is_hard_macro TRUE} or Liberty cell library attribute <is_macro_cell:true;>. Only the supplies, IO pins, and ports of hard macros are visible or accessible for integration and verification.

Terminal Boundaries: Any macro boundary is considered to be a terminal boundary. This straightforward and prevailing concept completely detaches the inside constructs and outside interfaces of macros from the external world. Oftentimes, an accidental global access to the inside a macro through UPF commands can modify the supply net, supply states etc. within a macro and may trigger an avalanche of functional failures when the macro is used in SoC level. So terminal boundary makes inside of a macro a black box and the ports on boundary at outside as drivers and receivers. This is implicated through set_port_attributes -driver_supply/receiver_supply.

Now that we have an understanding on the fundamentals of macros in UPF (low power) perspective, it’s time to understand how to integrate, verify and possibly reuse them – specifically, in bottom up integration perspective, we will discuss the extents of power domain boundary, terminal boundary, ancestor-descendant relations, power intent confinement, driver-receiver supply contexts, power states expectations, simulation state behavior, corruption semantics etc. We will comprehend our discussion on soft macro in this part 1 of 2 part series. We will then cover the solutions for hard macros in part 2.

It’s obvious from the definition of a soft macro given earlier that the system integrator must ensure that the macro is connected to the proper power supplies and that the boundary are properly protected with respect to both the parent and surrounding power domains that have signal crossings. The protection may specify isolation strategies with specific clamping requirements. It may also specify retention; hence it is required to ensure that backup supplies for the critical registers retain data during a power down. In addition, IP integrators must ensure that these constraints (isolation with clamp value, retention registers with etc.) are not violated when the soft macro is integrated into the entire system and configured according to their requirements. For verification, the soft macro power intent, or UPF, should be complete and independent and must not reference any object to its parent scope. This ensures that the verification tools can readily validate and catch any scenarios that fail to honor any of these constraints.

Figure 1. Standard SoC with Multiple Hard and Soft Macro Core Integrated

Also, the primary IO ports of the macro will not rely on the visibility of real driver and receiver supplies. That is, when driver and receiver supply attributes are present, IO ports will be annotated with these attributed supplies accordingly. However, when these supply attributes are absent, the driver and receiver supply will reference the primary supply set of its own top-level power domain. It is also important to know that the driver and receiver supply contexts for soft macro IO ports reveal that they are regarded as the terminal points, or terminal boundaries, with respect to the ancestor power domain instances for all verification and implementation tools. Such boundary conditions obviously paved the way to reuse the same macros over and over again across multiple projects. Tables 1 and 2 show different ways to construct power management schemes for soft macros.

Table 1: Modeling UPF Constraint for Soft Macro

It is important to observe here that the power domain of a soft macro is created with atomicity (with -atomic options or create_power_domain –elements {.} that contain its own top). This signifies that this domain can be merged but cannot be split during implementation.

On the other hand, a power model defined within begin ~ end_power_model or define_power_model {} and instantiated in a design with {UPF_is_soft_macro TRUE} may also represent a soft macro. The UPF intent within this power model describes the intent of the soft macro hardening process. So, based on the UPF power domain confinement, power model, and hardening process, the RTL instance of the macro belongs to the extent of the parent power domain as a hard boundary.

Table 2: Modeling Soft Macro and Its UPF

It is important to note that UPF 3.1 indicates that the UPF must be self-contained for macros. Hence it is also essential to know that the soft macro instance is considered to have a terminal boundary that restricts the scope of the object. That is why power intent objects expressed in an ancestor, like global supply sets, are not available to the block, and therefore the power intent must be supplied explicitly, even for soft macros.

Figure 2 shows the soft macro instantiated in tb.top_inst.I2.X5.Y5 in hierarchal windows on the upper left. The HDL code at the RTL is shown in the upper middle, and the corresponding atomic power domain PD2 is shown in the upper right. The reports from simulation results are shown in the lower left (where simulation considers the power model as a soft macro cell), and power domain status is shown in the lower right window (where the corruption status is shown as “unknown” since the macro didn’t specify any power states).

Figure 2. Soft Macro Power Model Verification

In this article we have identified and resolved the fundamental problems of integrating, hardening, and verifying soft macros in larger systems from a power aware design, verification, and implementation flow perspective. In order to sustain a pragmatic approach to reduce the complexities of reusing power aware macros, we identified that a self-contained UPF is essential. For soft macros, atomicity of the power domain, internal retention and external boundary strategies, legal power states, and sequencing between them are crucial.