What’s needed for power analysis in million-gate SoCs.
Source: Semiconductor Engineering
Power analysis has quickly become equally as important as functional verification for today’s power-hungry SoCs. Yet, until now, it was not possible to fully analyze dynamic power in very large SoCs running embedded software. That day has finally arrived with new emulation platform software that overcomes the intrinsic shortcomings of the current two-step power estimation tools.
The current approach for estimating dynamic power consumption consists of a file-based flow that evolves through two steps. First, a simulator or 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 signal database file such as FSDB or VCD. Then, a power estimation tool fed by an SAIF file calculates the average power consumption of a whole circuit, or an FSDB file computes the peak power in time and space of the design.
Figure 1: The two-step, power analysis file-based approach.
The method may be acceptable when the design-under-test (DUT) is relatively small and the analysis is performed within a limited time window of up to a million or so clock cycles. However, when applied to modern, large SoC designs of tens of thousands to millions of gates executing embedded software, three problems defeat the current approach:
1. The sizes of SAIF and, even more so, FSDB/VCD files become massive and unmanageable;
2. The file generation process slows to a crawl that extends to hours, possibly exceeding a day;
3. File loading into a power estimation tool extends to several days or more than a week.
The Veloce Power Application solution from Mentor Graphics overcomes these issues inherent to the two-step, file-based flow by tightly integrating the emulator to power analysis tools. The Veloce Power Application delivers two distinctive capabilities: Activity Plots and the Dynamic Read Waveform API.
An Activity Plot maps in one simple chart the global design switching activity over time as it is occurring, booting an OS and running live applications.
Figure 2: The Activity Plot identifies focus areas over long runs.
It identifies time frames of high switching activities 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 time 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 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 replacing the file-based approach with a Dynamic Read Waveform API for the signal data.
Once high-switching activity time frames are identified at the top level of the design, the design team can zoom into those frames. Users can dig deep into the hierarchy of the design and the embedded software to uncover the main source of such high-switching activity.
The Dynamic Read Waveform API replaces the cumbersome SAIF/FSDB/VCD file generation process by live streaming switching data from the emulator into the power analysis tool. All operations run concurrently, from emulating the SoC, design capturing switching data, reading switching data by the power analysis tool and generating power numbers. The net effect is a jump in overall performance from booting an OS and running real applications.
As a side benefit, the Dynamic Read Waveform API also delivers improved accuracy compared to SAIF-based average flows because conditional controls are incorporated automatically for switching.
So it’s time for cutting edge companies to cut the rug with a new dance that enables power analysis and exploration at the system level that is not possible with the old two-step, file-based flow.