Non-separation of power and performance

How much power does a system consume? The simplistic path to power estimation for a system used to be tossing a few metrics – standby, typical, worst case, with figures pulled from a datasheet, simulation, or physical measurement – into a spreadsheet. After filling the remaining holes with SWAG (scientific wild-ass guesses), and summing things up, there was a bottom line.

But, that bottom line on power was imprecise at best. Designers were usually after worst case, because it determined system cost. Worst case for a chip, derated appropriately, indicated how big a heat sink or fan and what kind of elastomeric goop (spewed from a tube like toothpaste, or more scientifically infused into pads and sheets) was needed. Worst case for a system, again with margin applied, suggested how big a power supply and what gauge wire to get.

Margin is expensive, and so are batteries, and worst case was nowhere near good enough for system design any more. Architects went looking for ways to squeeze chips, offering tradeoffs in performance for power, with the resulting summation meaning system improvements.

Some genius invented the idea of dynamic voltage and frequency scaling (DVFS), muscling up only when bigger workloads entered the pipeline. Other geniuses were off experimenting with sleeping, napping, dozing, hibernating, wake-on-packet, SleepWalking (an Atmel trademark), and a hundred other forms of various semi-conscious states. Still other geniuses were innovating with clock gating, and power domains, and other techniques to manage power block-by-block, retaining data and keeping operations intact.

All the while, geometries got smaller and leakage generally got worse, meaning architects had to understand not just function but process. On top of that, all the control knobs put in to save power meant software had to take charge of the panel, managing both the computation and the resources needed to execute it on a continuous timeline of operation.

We have entered the realm of power-aware software, with layers of complexity and nuances of precision that can make or break a product. Power and performance have become entirely non-separable, and must be explored earlier in the cycle to determine architectural choices pre-silicon. Virtual platforms, masters of functional modeling and simulation, are now coming to bear on the power-aware problem.

For the power architect, System C modeling and virtual prototyping may be foreign territory, but it is the only way to develop an accurate (that is, a non-SWAG) view. By viewing activity over time and including complex traffic scenarios in use cases, architects can uncover interactions and opportunities that are impossible to expose in a spreadsheet. Software designers can get an early look at how to manage workloads and avoid surprises, proactively understanding how choices can impact user experience and choosing the best approaches from what-if analysis.

Synopsys is outlining this new approach, using Platform Architect and Virtualizer power-aware IP block models, in an upcoming free workshop kicking off on June 10[SUP]th[/SUP] at Synopsys offices in Mountain View, CA. Patrick Sheridan, senior product marketing manager, will be exploring the steps in power-aware hardware and software development using virtual prototyping.

Attack Your SoC Power Challenges with Virtual Prototyping

In previewing this, I asked Pat about where this goes, recognizing that more power-aware IP models in System C will be needed, and both in-house and third-party IP designers will need to understand how to create them in a standard format. Maybe the Unified Power Format (UPF) that many SoC architects are familiar with could be extended from a power intent view into supporting system-level power modeling? It turns out the IEEE 1801 specification working group has kicked off just such an effort, with a system-level power subcommittee led by Alan Gibbons of Synopsys.

It took a while for functional designers to warm up to virtual prototyping, but as cycles have shortened and the benefits of hardware-software co-development have become clear, the approach has gained popularity. With the fate of mobile and other devices hanging in the balance of the power-performance tradeoff, the potential for virtual prototypes is evident. Now is the time for architects and software teams to ditch spreadsheets and SWAG, and get in on the ground floor of power-aware development.

lang: en_US