Breaking Down Power Management Verification

By Vijay Chobisa, Mentor Graphics Corporation

For system-level power management verification, it is important to understand how software applications running on the targeted SoC effect power use.  During system-level verification, it is imperative to verify that the software power control applications properly initialize power states and power domains. In addition, that signals are stable during the transition from one application to another or between tests and level shifters, and that isolation cells are inserted correctly.

Companies that design complex SoCs implement several power domains in their designs to meet power budgets while maintaining the required operating performance. Several low power management techniques are employed including isolation cells, level shifters, state retention cells, power aware memories, and power control logic. As some memories are power aware, memory behavior must also be validated at the system level. The power control logic resides in hardware and the actual controls come from software, making verification too complex and lengthy for traditional digital simulators.

An advanced emulation platform supports complete power management verification at the system level, where software and hardware operate together where real-world stimulus is applied to the design under test. The speed of emulation allows designers and verification teams to boot the operating system and quickly stress test the design over an extremely large number of power sequences.


A power management structure allows designers to divide designs into several power domains. Each domain can be operated with a unique voltage level and can be powered on and off without interfering with the functionality of other domains. This requires isolation between power ON domains and power OFF domains. When an OFF domain needs to wake up, it requires some basic information to return to ON correctly.  Designers use retention techniques to preserve this information while the domain is switched off. The more information retained, the more real estate consumed; but the domain wakes up faster. Designers must be aware that states in the power OFF domain that lack a retention infrastructure can go to unknown values. Level shifters are used to operate domains at different voltages.

Memories can switch to three different states: power ON (allows normal memory operations), power OFF (memory operations are disabled and memory contents are corrupted), and standby (memory operations are disabled but memory contents are kept intact).

In this system, the always ON block implements the isolation interfaces and schemes. Features of the UPF standard are used to accomplish this functionality: an always ON supply and an ON/OFF supply. The Veloce operating system (OS3) supports the UPF supply functions — supply_off/supply_on — to natively handle this behavior.

Together, the four stages described below create a scalable, progressive flow that allows users to begin system-level low power verification early in the design and verification flow, using high-level models, adding detail and accuracy as the design matures. The stage used depends on how far along the design and its corresponding UPF description is in overall development. Each stage has specific goals and actions that build toward full verification of the final netlist.


Semiconductor companies want to start low power verification as early as possible to shorten production schedules. To make this happen, it is critical that the UPF file accurately captures the design intent as the design blocks are coming together at an early stage (Figure 1).

figure-1Figure 1.  UPF file accurately captures the design intent.

At this stage, the design is in RTL, and the entire power intent is defined using top level UPF file. Typically it is carried over from a previous design and must be modified to suit the new one. The RTL is still in an early stage of development. There are no Liberty files and no gate-level components at this stage. The testbench is also in an early stage of development. Appropriately, verification takes place at a high level of abstraction, where speed is more important than accuracy.

First, engineers verify that the UPF file is correct, and then verify that the DUT and UPF file are working together—that the syntax matches. After that has been validated, the emulator reads the design RTL plus the UPF file, generates the power hierarchy along with the design netlist, and maps everything to emulation primitives. This step is used to verify the structure from the top level point of view to make sure that the emulator takes this UPF file and creates the proper power infrastructure in the DUT; including power switches, connectivity, and isolation cells. If anything is not implemented correctly or is missing in the UPF file, it is corrected both in the UPF file and the backend implementation.


In this stage, the design has several RTL blocks — each having its own UPF file. As in Stage 1, there are no gate-level netlists or Liberty files at this point.

The chip is verified with the top-level (power intent) UPF file and the UPF files for each block, which are usually supplied by the IP/block developers. Because each block-level UPF file has been implemented, they are more accurate at representing the power control inside each block. The top-level UPF file verified in Stage 1 is used at this stage, so the block-level and top-level UPF files are used together to thoroughly verify the whole design (Figure 2).

figure-2 Figure 2. The chip is verified with the top-level (power intent) UPF file and the UPF files for each block.

The verification runs are similar to those in Stage 1. The main difference is that the power control is more detailed and the main goal is to make sure that the internal block controls are working correctly in the whole chip environment. Because each power pin control is more complicated in this context, compared to Stage 1, a finer level of resolution is required to control different sequences and cover all the corner cases. It is essential to test the handshaking between these blocks in the system context, because although these blocks and their respective UPF files have been verified in isolation, it is important to verify that they interact correctly with other blocks at the system level.

Designs often have many power sequences coming from different voltage regulators, and these can be powered on and off at any time. Further, there is not a single source that is controlling all of this activity. These are the real- world behaviors, which engineers want to mimic in emulation. The emulator generates random power sequences that can randomly power the different blocks on and off, which mimics the random nature of real-world scenarios.


In stage 3, some components of the design are fully ready and are available as a gate-level netlist. For RTL blocks, power intent comes from a UPF file, and for gate level block power infrastructure, is part of the netlist. This requires support of a liberty file. These gate level block or IP could be reused from previous SoC (Figure 3).

figure-3Figure 3.  Designers test functionality in the hardware/software context.

At this point in the design cycle, the software is maturing and the CPU is used to control power down and power up functionality. So designers need to test this functionality in the hardware/software context.

The emulator must be capable of reading UPF files and liberty files to enable this mix of RTL and gate level netlist verification.  This is very critical at this stage.

As before, the accuracy of the UPF file matching the real chip is the primary goal. Toward that end, the emulator needs to provide power structure visual checking and the ability to report any mismatches. Again, only emulation can provide the required runtime performance to handle these complex operations on a very large chip, especially with gate level components.


In this stage, the power management infrastructure is part of the gate-level netlist and includes the final power hierarchy and reads the power strategy from Liberty files. This enables the final SoC netlist to be verified before chip tape out, ensuring that the final netlist has accurate low power behavior and avoiding translation issues from one design stage to another. Veloce identifies the power hierarchy and provides a debug flow in the event of incorrect or expected behavior (Figure 4).


Power aware bugs can be hard to debug thus a comprehensive GUI to debug power aware issues is needed. The Visualizer Debug Environment from Mentor offers a comprehensive power aware debug environments to enable debugging power aware issues, connectivity and sequences in an intuitive way.

Some examples:

  • PA domains
  • PA crossings capturing various aspects of isolation/level shifter being missed/incorrect
  • PA SimChecks
  • Power hierarchy schematic


Companies start power aware verification at a very early stage in the design flow and add details and granularities as the design progresses. The successive refinement at each stage allows customers to break down a complex problem into smaller, targeted verification jobs and establish a feedback loop to and from the backend team.

figure-4Figure 4. Final SoC netlist is verified before chip tape out.

The Veloce Emulation platform from Mentor allows users to approach power management verification at the system level, where both software and hardware operate together with real-world stimulus applied to the design under test. The speed of emulation lets designers and verification teams boot the operating system and run application stress tests on the design through a very large number of power sequences extremely quickly. The Veloce Emulation platform is fully aligned with the Questa® simulator from Mentor, enabling customers to use the same UPF files and UPF constructs for both simulation and emulation.

The emulation team at Mentor has worked with customers to create a system-level power management verification methodology that achieves thorough verification of the interactions between software and hardware and confirms that system resources are powered appropriately in each functional mode. This makes the Veloce Emulation Platform a logical choice for power management verification for companies who see advantages in using standards and avoiding non-standard methodologies. The Veloce Emulation Platform complies with the IEEE 1801 Unified Power Format (UPF 2.0 and 2.1) standards; including comprehensive constructs support and debug capabilities.

Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google
  • TwitThis