A New Approach to Accurate Dynamic Power Estimation of SoC DesignsBy eliminating a file-based flow, new tools offer a complete RTL power exploration and accurate gate-level power analysis process.

Source: EE Times

In a recent post, I highlighted the intrinsic limitations of the current approach to estimate dynamic power consumption. Briefly, the approach consists of a file-based flow that evolves through two steps. First, a simulator or an emulator tracks the switching activity, either cumulatively for the entire run in a switching activity interchange format (SAIF) file, or on a cycle-by-cycle basis for each signal in a fast signal database (FSDB) file. Later, a power estimation tool fed with a SAIF file calculates the average power consumption of the whole circuit, or an FSDB file is used to compute the peak power in time and space of the design (see Figure 1).

Figure 1. Conventional power analysis is grounded in a two-step, file-based approach.

Figure 1. Conventional power analysis is grounded in a two-step, file-based approach.

These techniques may be acceptable when the design-under-test (DUT) is relatively small — in a ball-park of a few million gates or less — and the analysis is performed within a limited time window of up to a million or so clock cycles. Such time windows are typical when the DUT is tested with adaptive functional testbenches.

However, when applied to one of today’s large SoC designs boasting tens or hundreds of millions of gates executing embedded software — such as booting an operating system and running application programs that require billions of cycles, for example — three problems defeat the conventional approach:

    1. The sizes of SAIF and, even more do, FSDB files become massive and unmanageable.
    2. The file generation process slows to a crawl that extends to hours, possibly exceeding a day.

File loading into a power estimation tool can extend to several days, possible a week or more.

It seems like a lost cause.

But things changed on May 27, 2015, when Mentor Graphics announced the Veloce Power Application — a software package with the Veloce Activity Plot and the Dynamic Read Waveform application programming interface (API) that sits on top of the Veloce OS3 (see Figure 2).

Figure 2. An OS shields any application from the underling hardware emulator.

Figure 2. An OS shields any application from the underling hardware emulator.

The Veloce Power Application addresses the core problems affecting the conventional (and controversial) approach to estimate power consumption. It eliminates the two-step, file-based flow by tightly integrating the Veloce emulator to the power analysis tool.

Design teams no longer have giant files to contend with. That is, no more wasted space, and no more lost days in file creation and file loading. The new approach provides a fast, clean, and very effective method to quickly and thoroughly estimate the power consumption of a modern SoC design.

Veloce Activity Plot
The Veloce Activity Plot maps in one simple chart the global design switching activity over time as it is occurring; for example, while booting an OS and/or running live applications (see Figure 3).

Figure 3. The Veloce Activity Plot identifies focus areas over long runs.

Figure 3. The Veloce Activity Plot identifies focus areas over long runs.

The plot identifies time frames of high switching activity that may pose power threats to the design team. While this chart is not unique, its creation is an order of magnitude faster than the generation of file-based power charts. As a data-point, Veloce takes 15 minutes to generate an Activity Plot of a 100-million gate design for 75-million design clock cycles. Power analysis tools could consume more than a week to generate similar information. Moreover, they may not even be able to handle such a large volume of data.

Of course, the next questions are: “Where” are those peaks happening in the DUT and “What” is causing them? This is addressed by the Dynamic Read Waveform API.

Dynamic Read Waveform API flow
Once high-switching activity time frames are identified at the top level of the design, the design team can zoom into these frames. Users are able to dig deep into the hierarchy of the design and into the embedded software to uncover the main source of such high-switching activity. To this end, they can use the Dynamic Read Waveform API.

The Dynamic Read Waveform API replaces the cumbersome SAIF/FSDB file generation process by live streaming switching data from the emulator into the power analysis tool. All operations run concurrently, from emulating the SoC, to capturing the switching data, to reading switching data by the power analysis tool, and generating corresponding power numbers. The net effect is a jump in overall performance as required to boot an OS and run real applications (see Figure 4).

Figure 4. The Veloce Power Application accelerates Veloce power analysis enabling design teams to perform generation, analysis, and estimation in one step.

Figure 4. The Veloce Power Application accelerates Veloce power analysis enabling design teams to perform generation, analysis, and estimation in one step.

As a side benefit, the Dynamic Read Waveform API also delivers improved accuracy compared to SAIF-based average flows, thereby permitting correct power estimation of memories and IP blocks.

The bottom line is that the Dynamic Read Waveform API enables power analysis and power exploration at the system level with software-based tests that are simply not possible when using a file-based flow.

Conclusion
The Veloce Power Application empowers a methodology shift in power estimation. By eliminating a file-based flow, the unique Dynamic Read Waveform API integration with power analysis tools offers a complete RTL power exploration and accurate gate-level power analysis process.

This means that the design and verification teams can commence RTL power exploration very early in the design cycle. They can perform power tradeoffs and architectural adjustments further upstream than ever before. Furthermore, they can continue to use the same process after RTL is synthesized into a gate-level representation. At the gate-level, they can attain more accurate power measurements and perform additional fine tuning before tapeout, and they can conclude with power signoff in a targeted application environment.

Dr. Lauro Rizzatti is a verification consultant. He was formerly general manager of EVE-USA and its vice president of marketing before Synopsys’ acquisition of EVE. Previously, Lauro held positions in management, product marketing, technical marketing, and engineering. He can be reached at lauro@rizzatti.com.

Leave a Reply

How can we help you?

If you are interested in more information regarding our marketing services, please contact us.

Looking for a First-Class Business Plan Consultant?