Power Management and IP Integration in SoCs: Part 2



Most IPs are available as software or hardware macros. But both pose immense challenges. This is especially the case when integrating them into low power designs and when verifying Power Consumption (PA), as the majority of IPs are standalone and pre-verified at the block level and they need to be preserved in their entirety when integrated or verified in the SoC level.

Part 1 of this two-part series on Power Management and Integrating IP into SoCs provided background information on the UPF standard, macros, endpoint limits, and PA verification challenges. associates, then discussed techniques for integrating and verifying IP software macros in the low power paradigm. This article will cover IP integration and verification techniques for hardware macro IP.

The power management and power intention of any design is derived from the UPF function. The most recent version, UPF 3.1, defines the formation of an anonymous power domain around hardware macros when it is outside of all other power domains. This new semantics is crucial for IP integration in SoCs and PA simulation. More precisely, the boundary conditions were not well defined until UPF 3.1 for hard macros (as well as for soft macros). As a result, low-power hardware and software macro checking solutions were not always intuitive, portable, or standardized.

The power supply intention (or UPF) of any hardware macro contains all kinds of important information: internal-external or driver-receiver power supplies, associated power supplies for the IO ports of the IP limit, isolation cells, level shifters , repeater cells and power modes states and / or voltage values. The UPF is expected to already be verified at the macro (or block) level. However, just like software macros, it is equally important to check the UPF that accompanies it throughout the system once the hardware macro is integrated.

The SoC integrator ensures that these macros are properly connected to the correct power supplies at the system level and that the limits are properly protected against the entire system in which the macro is placed. This will ensure that the verification tools can validate power management in the SoC environment and detect macro-related issues early in the design flow. Figures 1 and 2 show different ways of constructing power management diagrams for hardware macros.


Figure 1: UPF modeling for Hard Macro

Hardware 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 hardware macro designed in behavioral HDL, but hardware macros can also be instantiated as synthesized blocks at the gate level. When checking out, it’s important to remember that the hardware macro is just a black box for the rest of the design. Only the model interface is visible in the parent context. As a result, PA checking of hard macros has several verification use case Where use models depending on the availability of a set of macro HDL models, Liberty cells, and UPF objects in a particular verification environment.


Figure 2: Modeling of the hard macro and its UPF

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

  • Door-level HDL or netlist macro behavior model, Liberty cell library and stand-alone UPF with the top level power domain of the macro defined using create_power_domain -elements {.}
  • Door-level HDL or netlist macro behavior model, Liberty cell library and UPF without the first level power domain of the macro defined
  • Gate-level HDL or netlist macro behavior model and Liberty cell library

All Liberty attributes can be easily derived from the combination of HDL and UPF attributes and commands. Thus, a Liberty cell library is not required for (a) and (b). Although each set of the above usage patterns looks different, all of the sets tend to extract the exact or similar information for AP verification.

Case (a) started as a macro and then hardened during the implementation process. Here, the same stand-alone 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 software and hardware macros contain create_power_domain -elements {.}. Thus, like software macros, the behavioral or gate-level HDL netlist of the hardware macro instance is within the scope of its own parent power domain. Because the macro is a black box for the rest of the design, each I / O port in the hardware macro is considered a terminal boundary. For (b), the accompanying UPF is defined without its own top-level power domain, so it is intended that the UPF, at a minimum, specify the driver and receiver provision attributes for macro ports. Here, the hardware macro instance or one of its I / O ports does not belong to the scopes of any parent power domain. This relation also applies for (c). The physical interpretations and black box concepts of hardware macros make it clear for (b) and (c) that regardless of whether the related supplies of these IO ports are different or not, all IO ports in a hardware macro will be considered as terminal limits. . Additionally, just like software macros, a power model defined in begin / end_power_model but instantiated in a design with {UPF_is_hard_macro TRUE} can also represent a hardware macro. The UPF intention within this power model describes the intention in such a way that the macro has already been strengthened throughout the implementation process.

Great concern remains regarding the extent of a power domain for 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 scope of the power domain of the macro instance, it will be included in the scope of its ancestor power domain. Therefore, all unconnected PG pins of the macro will then be associated with the primary power supply of the ancestor instance power domain.

However, from the point of view of the physical interpretation of hard macros, it is appropriate to consider that such cases of hard macros belong to an independent power domain that will be fed from the main power of the ancestor domain. This separate power domain, which is defined as “a new anonymous power domain (a PD) “in UPF 3.1, ensures that all ports in the macro will be considered power domain boundary ports relative to the ancestor instance’s power domain.

Since it is now clear that the methodological solutions that we have explained here revolve around the concept of terminal boundary, we need to further explain the simulation semantics of set_simstate_behavior and UPF_simstate_behavior specifically for cases implied by the “new anonymous power domain” for hardware macros not explicitly defined as confined in a power domain. When the two {UPF_is_hard_macro is TRUE} and {set_simstate_behavior ENABLE} are given, then the sim port and state corruption semantics will be applied to those anonymous power domain macro instances.

It is not backward compatible with previous LRMs; however, it allows more precise and pessimistic simulations. Users can, however, override the corruption by explicitly specifying the set_simstate_behaviour command on a particular model or a particular instance of a model. Additionally, the UPF 3.1 standard also defines semantics for port or Liberty based corruption through commands such as UPF_related_power / ground_port, related_power / ground_pin, and power_down_function. It may appear that a PD, port-based and simstate corruption combined remove user checks so that a PD primaries are the same as its primary parent Yet users still have the freedom to explicitly define a template or macro instance simstate_behavior To PORT_CORR_ONLY, or they can put the macro instance in a power domain as in case (a) above.

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

Figure 3 shows the hardware macro check environment. The named hard macro Hmacro is instantiated in tb.top_inst.Hmacroinst in the hierarchical windows at the top left. The UPF 3.1 power model code is displayed at the top middle. The corresponding power range PD is displayed at the top right. The Liberty file present in the check is displayed at the top right. Reports of simulation results are displayed at the bottom left (where the simulation considers the power model as a hard macro-cell), and the state and variables of the power domain are displayed in the windows at the bottom right .


figure 3: Hard macro power model verification environment

In this two-part series, we have identified and resolved the fundamental issues of integrating, hardening, and verifying software and hardware macros in larger systems, from a power-sensitive design and verification perspective. . For hard and soft macros, a stand-alone UPF is essential. For hardware macros, it is mandatory to provide specifications for associated power supplies of peripheral ports, for external and internal power supplies and their characteristics, for internal power states of power supply networks and switches, and for policies internal and external limits with information and power system. – power level states.


Previous Even for available domain names, it is not possible to leave the WHOIS history to chance
Next Coming soon: Internet domain names in Hebrew