Power and Thermal Simulation in ESL Verification Flows

At the recent DVcon there was a keen focus on design verification and validation. Much of the attention is on Logic/circuit design verification, UVM, and IP verification. At the system level functional verification has improved to comprehend complex hardware and software interaction using Virtual Platforms/SystemC and Transaction Level Model simulation that complements the software development and debug activities. The backend validation remains a complex task, which often delays successful product launch and adoption. Designs must now also satisfy use case specific and scenario dependent power and thermal targets. These requirements are defined by marketing and the customers at inception and successful designs must converge on these targets much earlier in the development process. Complete system level verification and software validation must also comprehend the power and thermal validation flows in the verification area. UVM and IP verification is good and necessary, however, complex SoC verification also requires dynamic and coupled simulation to meet power targets, verify power management and validate thermal management algorithms and policy.

If your new SoC design uses software based policy decision making or autonomous embedded power/thermal management controllers, hardware, behavioral sensors and micro-sequencers to implement power and thermal management, then this becomes part of the verification flow. The question then becomes, when do I verify power and thermal, early at the ESL level or later at the RTL level? My hunch is that earlier at the ESL level makes more sense, because at the early stage you have more impact in making trade-offs than at the RTL stage where it’s too late to make such trade-offs. Typical questions that need to be answered about power verification include:

• Will my design meet the power specified in the customer requirements and component data sheet?·
• What is Idd across frequency, voltage and temperature for a range of conditions?
• How does power and temperature vary for each and every power state/power mode: for example Turbo, Active, Idle, Idle with clock gating, Idle with power gating, retention and sleep states?
• Can I guarantee items like MP3 playback, talk time, video encode/decode and associated battery life?
• What invokes the power state transitions, their entry and exit latencies and how does this affect the resulting power/Idd calculations or estimation?
• How does the software device drivers, core/micro-controllers micro-code and system firmware affect power?
• How does OS-directed power management affect power?

To get any of these answers requires early power modeling at the ESL level, and a company called Docea Power is focused on such power modeling and simulation.

Power Simulation

Docea Powerhas an ESL tool for power simulation and validation called Aceplorer. Here’s what the flow looks like for Aceplorer:

With Aceplorer your SoC power model can account for both dynamic and statistical use cases, allowing you to explore and then optimize the best power management strategy considering both hardware and software. This task is well-suited for an ESL approach. Power models can be created and refined as your design progresses but not gated by RTL and circuit level details. Imagine being able to run your operating system and apps to see how they impact power before your design is completed.

Thermal Simulation

Knowing the thermal response of your SoC before silicon is quite important in meeting specs, however it does require both power and thermal modeling and a coupled power-thermal simulator. Thermal sensors placed within an SoC and the system design provide dynamic feedback to your system when thermal limits are reached. Software and hardware policy engines can control the thermal mitigation scheme which can alter the system operating point frequency and voltage in response to the resource demands of the application and the environmental/physical conditions.

Docea Power also has an ESL tool that creates compact thermal models which can be used analyze power and temperature over time, solve power as a function of temperature and help optimized power and thermal management policies.

With the Docea approach you can use SystemC and TLM models to drive the power and functional models, not only calculating power and temperature
but also tracking the power event and thermal event triggers and the resultant change in behavior of an application. This approach isn’t just for software debug and software development, rather it’s a way to verify complex power state and power event transitions, converge on power targets
and account for design specific parameters that most IP are affected by:

• Power supply and voltage network
• Clock networks
• Control of the voltage and clocking, plus the interaction with software and applications

Using a co-simulation with a power and thermal ESL model does enable rapid simulation speed, ease of use of configuration and multi-case testing. This answers three basic questions:

• Did I converge on my power targets for all use cases?
• Did I verify the firmware, software and drivers with the hardware interaction for all power and thermal state modes and state transitions?
• Does this have a noticeable or negative impact on performance, latency, responsiveness or QoS of the applications required for proper use of the IP or system?

Summary
For you next SoC design, why not consider modeling and simulating for both power and thermal at the ESL level?

lang: en_US

Share this post via:

• 
• 
• 
•