Software-driven power analysis

Power tends to cost; high power costs highly. This rather forced adaptation of Lord Acton’s famous quote captures two important aspects of semiconductor design and power consumption. Looking at average power consumption over time, it is clear that a chip with high power draw will incur high costs. In portable devices, more power means either larger and more expensive batteries, or shortened battery life. Further, more power means more advanced and more expensive packaging to dissipate the resulting heat. These three factors also have ripple-effect costs in terms of product pricing, profit margins, and likelihood of success in the market.

Concerns over power consumption extend well beyond portable devices that run at least part of the time on batteries. Wall-powered devices also incur extra costs in terms of packaging, power supplies, and power distribution systems. These same issues extend all the way to server farms, with their racks or compute servers, massive data storage arrays, and network switches. The operational costs for server farms are enormous; studies have shown that the bills for power exceed the price of the hardware itself over the lifetime of each server. Server farms may be located near hydroelectric dams or massive solar arrays in an attempt to meet their high demands. Some locations must also meet “green laws” that regulate server power draw.

At the high end, excessive power consumption may require liquid cooling systems that add enormous infrastructure and associated costs. For all these reasons, reducing average power consumption is a goal in nearly all semiconductor projects, regardless of the end market. When considering peak power, reduction may be a critical need rather than just a goal. Some chips are designed so that only certain portions may be running at the same time. In such cases, turning on all functionality may require more current draw than the device can handle, resulting in thermal breakdown and permanent damage.

Challenges of power analysis

Given all the motivation to limit power consumption, the industry has developed a wide variety of low-power design techniques. These range from layout-level circuit tweaks to system-level, application-aware, software-based power management. Whatever techniques are used, it is very valuable to be able to accurately assess their impact by estimating both average and peak power consumption during the design and verification of the chip under development. It is unacceptable to wait until after fabrication to find that the average power is too high for a viable product or that the peak power draw destroys the chip. Effective pre-silicon power analysis, preferably at multiple stages in the project, is required.

The electronic-design-automation industry’s traditional approach to power analysis relies on simulation. Functional verification of the chip entails developing a testbench and then writing or generating a suite of tests that check each function or feature of the chip design. It is a relatively simple matter to simulate the entire test suite, or perhaps only a representative portion, and feed the results into a traditional power signoff tool. Since most power consumption occurs only when circuits switch state, the simulator can provide a switching activity file to a power signoff tool. When combined with the power characteristics in the library for the target technology, the tool can provide a fairly accurate estimate for both average and peak power consumption.

This accuracy, however, is entirely relative to the tests that are run in simulation. In practice, any verification test suite is not representative of chip operation with production software running. Tests designed for functional verification, by intent, focus on stimulating only those areas of the design needed for the targeted feature. Constrained-random testbenches can generate more parallel activity but are still unlikely to model real-world usage. Truly accurate power analysis can be performed only by using the switching activity from real software workloads, including user applications running on top of an operating system (OS).

It typically takes a few billion clock cycles to boot an OS, start system services, and run applications. This would be completely unpractical to run in simulation. In contrast, emulators routinely run billions of cycles, from OS boot to multiple user applications running in parallel. Emulation exercises just the sort of real software workloads needed to perform high-accuracy power analysis. The challenge is that power signoff tools are designed to handle thousands of cycles, not millions, and most certainly not billions. A new methodology is required to identify a few areas of high activity in the emulation run and focus on using only these windows for power analysis (Figure 1).

click for larger image

Figure 1. Power analysis using power windows (Source: Synopsys)

Moving to software-driven power analysis

The first requirement for the flow shown in Figure 1 is for the emulator to produce a profile showing which parts of the design are active over time. This activity profile can be viewed as a graph within a waveform viewer or other hardware debug tool. Since power signoff cannot be performed on billions of cycles, the next step is for users to leverage the activity profile to identify one or more power critical windows during which activity is the highest and power consumption is likely to be the highest as well. If each of these windows is in the millions of cycles, it can be used for the next stage of power analysis. As a benchmark, the emulator should be able to produce an activity profile for one billion cycles of software workload in three hours.

Emulators do not generate activity profiles by default; a novel power analyzer tool is required to create a weighted activity model and load it in the emulator along with the design. Adding multi-threaded power analysis engines to the emulation run produces the profiles that enable users to analyze power usage of their designs systematically when executing multi-billion-cycle, complex software workloads. Users can run this power analysis step as soon as the register-transfer-level (RTL) design is ready. Since power estimation grows more precise for each stage in the implementation flow, users can run the same analysis on the post-synthesis gate-level (GL) netlist (see Figure 2). Since total power consumption is the target metric, whenever possible the complete chip-level RTL or netlist should be used.

click for larger image

Figure 2. Selection of power critical windows (Source: Synopsys)

The next step in the process is to replay (re-run) each power critical window in the emulator to generate much more detailed information on power consumption and switching activity. Since this can be a great deal of data, it is impractical to run the entire multi-billion-cycle workload. The emulator must support save and restore so that each portion of the workload identified as a power critical window can be replayed by itself quickly and easily. For the replay, emulation can start at the save/restore point closest to the window. The emulator must also be able to record stimuli during a test run so that the replay happens deterministically. These same requirements apply for efficient debug in emulation as well as for practical power analysis.

The results from the power critical window replay are fed into the power analyzer, which produces two results. The first is a switching activity interchange format (SAIF) file, which documents the switching activity of every signal in the design. As a benchmark, this flow should be able to generate a 100 million cycle SAIF file from 1 TB of emulation data in two hours. Given appropriate output from the emulator, this file can be 100% accurate. As such, it provides deep insight into design activity and enables more accurate power consumption estimation. The SAIF file generated by the power analyzer is fed into the power signoff tool (see Figure 3), which calculates the average power consumed during the window. This is very useful for users trying to understand the power requirements for the final chip.

click for larger image

Figure 3. Estimation of average power (Source: Synopsys)

The power analyzer also generates cycle-by-cycle power consumption values for the entire power critical window. Users can view this information in the debug tool and use it to select one or more power signoff windows where highly accurate power estimation is needed (see Figure 4). In addition to the completeness of the SAIF file, the power analyzer has access to the detailed libraries for the target chip technology, including power characteristics. Thus, power analysis at this stage is typically 95% accurate when compared to the final chip. The user can feed the power signoff windows to the power signoff tool to refine the power analysis even further. The power signoff tool can calculate peak power for the window, allowing the user to ensure that power consumption stays within the physical limits for the chip. If IR-drop analysis is required, one or more event windows can be selected to run in the appropriate tool.

click for larger image

Figure 4.Selection of power signoff windows (Source: Synopsys)

Since later refinements in the design flow enable more accurate power analysis, the user may wish to run the power analyzer and the power signoff tool on RTL, the post-synthesis netlist, and the placed-and-routed netlist. The user might also want to analyze a netlist with an engineering changed order (ECO) implemented in it to be sure that power consumption has not been affected materially. Users should be able to create both a zero-delay waveform for fast analysis using the backend tool capabilities or a more accurate delay-annotated waveform for more accurate backend analysis (see Figure 5).

click for larger image

Figure 5. Power analysis calculations for multiple delay models from a single emulation run (Source: Synopsys)

Real-world results

Synopsys offers a software-driven power analysis flow that meets all the requirements previously discussed (see Figure 6). It greatly reduces the risk of missing critical power issues by enabling use of realistic software workloads rather than synthetic tests. It delivers accurate average power and cycle power results for multi-million cycle windows 1,000 times faster than simulation-based approaches. The following table shows examples from real-world customer designs:

Application Emulated

Cycles

Output Format Time
Mobile SoC 10M SAIF 2.5 hours
Processor 120M SAIF 2 hours
Processor 400M SAIF 4 hours

The flow supports emulation efficiency by reusing emulation results when analyzing power for different gate-level implementations. The power analysis flow integrates with familiar debug technology, enabling users to efficiently and accurately pinpoint and fix power-related issues.

click for larger image

Figure 6. Synopsys software-driven power analysis flow (Source: Synopsys)

Summary

Power consumption is now a major concern for developers of many chips and systems, from portable, battery-operated devices to the largest racks of compute servers. Power requirements appear even in the earliest product specifications, low-power design techniques are employed throughout the development process, and accurate power estimates are required at multiple points in the process. These calculations must be made using real software workloads running in emulation to predict both average and peak power. The software-driven power analysis flow outlined in this article uses the most advanced technologies and techniques for a solution much faster and far more accurate than traditional simulation-based methods. A commercial implementation of this flow is available today. To find out more about Synopsys emulation products please visit https://www.synopsys.com/verification/emulation.html.


Dr. Johannes Stahl is Senior Director, Product Marketing, Emulation, at Synopsys, where he is responsible for emulation and Verification Continuum solutions marketing. He has more than 25 years of industry experience including technical and business responsibilities for tools and services for SoC design and software development. Before Synopsys, Dr. Stahl had marketing responsibility in the executive team at CoWare, where he was managing major product lines as well as all IP partner relationships. Dr. Stahl holds Dipl.‐Ing. and Dr.‐Ing. degrees in Electrical Engineering from Aachen Technical University, Germany.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.