A Four Stage Flow for Power Management Verification

A four-stage power management verification flow allows engineers to begin system-level low power verification early on.

After power management structures have been added to a design, power management verification at the system level is critical to make sure the entire system operates as expected while software applications are running on the targeted SoC. It is vital to verify that the software power control application properly initializes power states and power domains. In addition, that signals are stable during transitioning from one application to another or between tests and level shifters, and that isolation cells are inserted correctly.

It is a common practice for companies that design complex SoCs to implement several power domains in their designs to meet power budgets while maintaining the required operating performance. These companies use several other low power management techniques 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 as well. 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 emulation platform can support complete power management verification at the system level, where software and hardware operate together applying real-world stimulus 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.

Power management verification flows
Low power management 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 come back 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 will wake up faster. Designers must be aware that states in the power OFF domain that lack a retention infrastructure will 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. Veloce OS3 supports the UPF supply functions — supply_off/supply_on — to natively handle this behavior.

This article describes a four-stage power management verification flow. Together, the stages create a scalable, progressive flow that allows engineers to begin system-level low power verification early on, using high-level models and then 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, building toward full verification of the final netlist.

Stage 1: Verifying UPF accuracy and implementation

Semiconductor companies want to start low power verification as early as possible to shorten their production schedule. Thus, it is critical that the UPF file accurately captures the design intent as the design blocks are coming together at a very early stage (Figure 1).

CD Spring Mentor F1
Figure 1

At this stage, the design is in RTL, and the entire power intent is defined using the 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 must verify that the UPF file is correct, and then they 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.

Emulation is required to handle large capacity chips and end-to-end test for running required power sequences.

Stage 2: Adding multiple blocks and corresponding block-level UPF files

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 utilized at this stage, so the block-level and top-level UPF files are used together to thoroughly verify the whole design (Figure 2).

CD Spring Mentor F2
Figure 2

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.

Stage 3: Mix of RTL and gate-level netlist

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 blocks or IP could be reused from previous SoCs (Figure 3).

CD Spring Mentor F3
Figure 3

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, which 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.

Stage 4: Verifying gate-level netlists

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. The Mentor Graphics Veloce emulation platform identifies the power hierarchy and provides a debug flow in the event of incorrect or expected behavior (Figure 4).

CD Spring Mentor F4
Figure 4

Advance low power debug console
Power aware bugs can be hard to debug thus comprehensive GUI to debug power aware bugs is very much needed. The Visualizer Debug Environment from Mentor Graphics offers a sophisticated power aware debug environments to enable debugging power aware issues, connectivity and sequences in an intuitive way (Figure 5).

Some examples:

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

CD Spring Mentor F5
Figure 5

Power management verification is critical. Companies start this type of 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 projects and establish a feedback loop to and from the backend teams.

The Mentor Graphics Veloce emulation platform enables companies to do power management verification at the system level, where both software and hardware operate together with real-world stimulus to the design under test. The speed of emulation allows designers and verification teams to boot the operating system and run application stress tests on the design through a very large number of power sequences extremely quickly. The – platform is fully aligned with the Questa® simulator from Mentor, enabling engineers 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 utilizing standards and avoiding non-standard methodologies wherever possible. 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


Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.