Key Ingredients for ESL Power Modeling, Simulation, Analysis and Optimzations

Key Ingredients for ESL Power Modeling, Simulation, Analysis and Optimzations
by Daniel Payne on 03-07-2014 at 6:00 pm

There’s a French EDA company named DOCEA Powerthat is uniquely focused on power analysis at the ESL level and I had a chance to interview Ridha Hamza to get new insight on ESL design challenges and their approach. Ridha started out doing SRAM design at STMicroelectornics in the 1990’s, moved into the emerging field of MEMS, and finally joined DOCEA Power four years ago.


Q&A

Q: What should I look for in ESL power tools?

There are three ingredients to a good system level power simulation and hence power optimization strategy:

  • A good power model (the HW)
  • A timed scenario (the SW)
  • A thermal model (the Physics!)

In this triptych, the software is the most obscure beast. Design teams focus on what they know best: the power model and as such it is the hardware representation down to the RTL, circuit and IC layout. They link to the packaging teams for the thermal model and physical description. Software stays obscure as it comes usually with no notion of time or events. And the notion of time is important for power saving. At the current pace of market introductions, chips and devices are often shipped with power management software that is sub-optimized. This translates into mobile devices that are only mobile for a short while, and unhappy end-users.

Q: How should HW and SW teams design for power?

In many applications though, the HW design teams implement very sophisticated mechanisms to save power. Dedicated power domains, enabling power gating, Dynamic Voltage and Frequency Scaling mechanisms, back bias control, etc… The issue is, if the software teams don’t use them, it is just a waste of resources and design/verification effort.Yet, within the HW teams, video, audio telecommunication architects and experts who understand the sequence of how the decoding happens work extensively with power architects on defining optimized power managementstrategies. About one hundred use cases for a wireless chipset are optimized at a platform level. What makes this extensive work not translating into the power management SW in time?

Lack of use case models, that is, a model of how the software is using the hardware. Lack of models is what makes the power management software debug and validation take time. And after silicon, time is scarce and comes at a high price. So even though software gets developed before silicon nowadays, it is hard to debug it in time…

From a user’s experience, nothing is worse than using buggy software, you will agree, especially if it sucks all the power from your battery at a fast pace. Software teams are given a power number to match for each use case. But that number says little about how it is obtained precisely. What software validation teams need is a model that shows how the ideal power management strategy is played in time, so they can match this with the real software.

There are many ways to get a timed representation, and even a representation by time slices can be useful. Timed TLM platforms, traces from previous projects, software monitoring that translates in timed use cases.

Q: How does DOCEA help me to optimize power at the ESL level?

At Docea, we have developed a solution that enables engineers to build timed use cases or to import them from different sources: (approximately or loosely timed) TLM platforms, traces from development boards obtained bymonitoring the software execution or from any mix of sources.


ESL Power flow using Aceplorer

Q: What approach do you recommend for optimizing power at the ESL level?

For a successful power optimized design the power model cannot just be the hardware and gate toggling or the RTL equivalent implementation. The power model needs to include the power intent, (the supply voltage domains, VR efficiencies, level shifters, power gates), the power events which alter the power consumption and the workload/software which excites the power model. The software needs to have some notion of time and either a loosely or approximately timed set of activity and power events. The co-simulation of the software workload either from real traces, post processed VCD annotated with power events that interact with the power management hardware for frequency, voltage and task consumption.


​Modeling and optimization flow

lang: en_US