Power Management And Integration Of IPs In SoCs: Part 2

Most IP are available as either soft or hard macros. But both pose immense challenges. This is especially so when integrating them into low power designs and conducting power aware (PA) verification, because the majority of IP are self-contained and pre-verified at the block level and they must be preserved in their entirety when integrated or verified in the SoC level.

Part one of this two part series on power management and integration of IP in SoCs provided general background on the UPF standard, macros, terminal boundaries, and associated PA verification challenges, then discussed soft macro IP integration and verification techniques in the low power paradigm. This article will cover IP integration and verification techniques for hard macro IP.

The power management and power intent for any design comes by virtue of UPF. The most recent version, UPF 3.1, defines the formation of an anonymous power domain around hard macros when it lies outside all other power domains. This new semantic is crucial for IP integration into SoCs and PA simulation. Specifically, boundary conditions were not well-defined until UPF 3.1 for hard macros (as well as for soft macros). Consequently, low power hard and soft macro verification solutions were not always intuitive, portable, or standardized.

The power intent (or UPF) for any hard macro contains all kinds of important information: internal-external or driver-receiver supplies, related supplies for the IP boundary IO ports, isolation cells, level-shifters, repeater cells, and modes of power states and/or voltage values. It is expected that the UPF is already verified at the macro (or block) level. However, just like soft macros, it is equally important to verify the accompanying UPF within the entire system once the hard macro is integrated.

The SoC integrator ensures that these macros are properly connected to the appropriate system-level supplies and that the boundaries are properly protected with respect to the entire system wherein the macro is placed. This will ensure that verification tools can validate power management in the SoC environment and catch issues related to the macro early in the design flow. Figures 1 and 2 show different ways to construct power management schemes for hard macros.

Figure 1: Modeling UPF for Hard Macro

Hard macros are available as an HDL behavioral model for verification or as a Liberty cell for implementation. Here we have shown the use case of a hard macro that is designed in behavioral HDL, but hard macros can also be instantiated as synthesized gate-level blocks. During verification, it is important to remember that the hard macro is just a black box to the rest of the design. Only the interface of the models are visible in the parent context. As a result, PA verification of hard macros has several verification use cases or use models based on how a set of macro HDL models, Liberty cells, and UPF objects are available in any particular verification environment.

Figure 2: Modeling Hard Macro and Its UPF

The possible and acceptable combination of these components for any PA verification use model are:

• HDL macro behavioral model or gate-level netlist, Liberty cell library and self-contained UPF with the macro’s own top-level power domain defined using create_power_domain -elements {.}
• HDL macro behavioral model or gate-level netlist, Liberty cell library and UPF without the macro’s own top-level power domain defined
• HDL macro behavioral model or gate-level netlist and Liberty cell library

All the Liberty attributes can readily be derived from the combination of HDL and UPF attributes and commands. So a Liberty cell library is not mandatory for (a) and (b). Although each set of the above use models seems different, all the sets tend to extract the exact or similar information for PA verification.

Case (a) started out as a soft macro and later got hardened through the implementation process. Here the same self-contained UPF with its own top-level power domain is used for both verification and implementation. It is important to note that the UPF files for both the soft and hard macros contain create_power_domain -elements {.}. So, similar to soft macros, the behavioral HDL or gate-level netlist of the hard macro instance belongs to the scope of its own parent power domain. Since the macro is a black box to the rest of the design, every IO port in the hard macro is considered a terminal boundary. For (b), the accompanying UPF is defined without its own top-level power domain, so it’s expected that the UPF, at the very least, specifies the driver and receiver supply attributes for the macro ports. Here the hard macro instance or any of its IO ports do not belong to the extents of any parent power domain. This relationship equally applies for (c) as well. Physical interpretations and black box concepts of hard macros make it evident for (b) and (c) that regardless of whether the related supplies of these IO ports are different or not, all the IO ports of a hard macro will be regarded as terminal boundaries. Also, just like soft macros, a power model defined within begin/end_power_model but instantiated in a design with {UPF_is_hard_macro TRUE} may also represent a hard macro. The UPF intent within this power model describes the intent in such a way that the macro has already been hardened through the implementation process.

One big concern still remains regarding the extent of a power domain for the hard macro instances in the case of (b), where the parent or ancestor scope is undefined, and for (c), where the UPF itself is absent. For such cases, if we query the extent of the power domain of the macro instance, it will be included in its ancestor power domain scope. Consequently, any unconnected PG-pins of the macro will be then associated to the ancestor instance power domain primary supply.

However, from a hard macro physical interpretation perspective, it’s appropriate to consider such cases of hard macros to belong to an independent power domain that will be powered by the primary supply of the ancestor domain. This separate power domain, which is defined as “a new anonymous power domain (ano PD)” in UPF 3.1, ensures that all the ports of the macro will be considered as power domain boundary ports with respect to the ancestor instance power domain.

Since it’s clear now that the methodological solutions that we have explained here pivot on the terminal boundary concept, we need to explain further the simulation semantics of set_simstate_behavior and UPF_simstate_behavior specifically for cases implicated by “new anonymous power domain” for hard macros not explicitly defined as confined in any power domain. When both the {UPF_is_hard_macro is TRUE} and {set_simstate_behaviour ENABLE} are given, then both port and simstate corruption semantics will be applied to such anonymous power domain macro instances.

This is not backward compatible with previous LRMs; yet it enables more accurate and pessimistic simulations. Users can, however, override corruption by explicitly specifying the set_simstate_behaviour command on a particular model or particular instance of a model. In addition, the UPF 3.1 standard also defines the port or Liberty based corruption semantics through commands like UPF_related_power/ground_ port, related_power/ground_pin, and power_down_function. It may appear that ano PD, port based, and simstate corruptions combined together take away user controls such that ano PD primaries are the same as its parent primary Yet, users still have the freedom to explicitly set macro model or instance simstate_behaviour to PORT_CORR_ONLY, or they can put the macro instance in a power domain like in case (a) above.

Questions may also arise regarding corruption semantics to UPF strategies internal to these hard macros. While the terminal boundary makes the internal of macros a black box, if, for example, the user’s UPF specifies retention and the macro contents the functional retention flops/latches, verification can model the retention behavior within the macro. Unfortunately this is not well discussed or clarified in latest UPF 3.1 LRM. When it comes to hard macro verification, such boundary conditions and constraints allow you to reuse the verified hard macros across different projects.

Figure 3 shows the hard macro verification environment. The hard macro named Hmacro is instantiated in tb.top_inst.Hmacroinst in the hierarchal windows on the upper left. The UPF 3.1 power model code is shown in the upper middle. The corresponding power domain PD is shown on the upper right. The Liberty file present in the verification is shown on the extreme upper right. The reports from simulation results are shown at the lower left (where simulation considers the power model as a hard macro cell), and the power domain status and variables are shown in the lower right windows.

Figure 3: Hard Macro Power Model Verification Environment

In this two-part series, we have identified and resolved the fundamental problems of integrating, hardening, and verifying soft and hard macros in larger systems, from a power aware design and verification perspective. For both hard and soft macros, a self-contained UPF is essential. For hard macros, it is mandatory to provide specifications for related supplies of boundary ports, for external and internal supplies and their characteristics, for the internal power states of power nets and switches, and for the internal and external boundary strategies with supply information and system-level power states.