“Once upon a time, you would complain if your cell phone didn’t work on one [battery] charge,” said Qi Wang—Cadence Technical Marketing Group Director for Low-Power Solutions—during his EDPS presentation in Monterey last week. “After Apple introduced the iPhone, your expectation is that the phone might go for a day before needing a recharge.” Why? Because we understand that the phone is now doing a lot more than it once did, said Wang as he entered into the main part of his talk.
We’d like to think that achieving closure on power-consumption goals during the design process is smooth and deterministic. The idealized work curve looks something like this in our heads:
But the reality is something quite different. Currently, we really cannot correlate power consumption with RTL design descriptions. We don’t really account for the way power consumption fluctuates with the application(s) being executed. Purchased or reused IP may not have the power models necessary for good power simulation. Results from power-simulation engines in the diverse design tools used during the entire design process are poorly correlated. With all of these factors and more, the actual path towards power-consumption closure looks more like this:
It’s a highly non-linear and non-deterministic path and Wang walked the EDPS audience down this path.
In the early stages of design, during chip architecture and planning, there’s currently no visibility into the power-consumption behavior of the design because the high-level models at these stages lack the required power-intent data.
Then the RTL coding starts and because the RTL tools also lack an understanding of the power-intent goals (and also because conventional wisdom is to synthesize for small area or maximum performance rather than power). Every once in a while, the SoC design team might take a crack at predicting power and, finding it wildly at odds with the goals, iterates on the design with power in mind.
During the validation and verification runs, different test cases will exercise different parts of an SoC’s design, producing different power profiles—resulting in even more design iterations.
In addition, internal IP being reused and a lot of purchased black-box IP lack the power models or design intent information needed to factor in the power-consumption characteristics of the IP.
You get even more design iterations as you ping-pong among different design tools that incorporate different power-simulation engines.
Then you start to run the actual system and application software on the design simulation and discover entirely new power profiles that had not yet been exercised during all of the previous design effort. The result is more iteration.
Even the SoC package configuration and the way the chip is cooled in the system will affect the device’s power consumption. These effects will alter yield and reliability results.
Any and all of these experiments cause rework, which increases design cost and delays tapeout. Sometimes, the SoC design team will discover that it needs to completely re-architect the design because the architecture has reached a dead end with respect to power consumption.
Starting over may be possible, but it can easily kill the project and the company. That’s a bad thing.
Why do we find ourselves in this situation? Because says Wang, some design teams are still in the age of home-grown design-for-power methodologies where there’s no standard way to express power intent so there’s no way for various design tools to use that sort of information except in an ad hoc manner. The result of this approach is a highly disrupted design flow, said Wang.
The first part of a solution is a standardized way of expressing power intent so that all of the design tools can exchange power-consumption information at various abstraction levels.
The other part of the solution is to then have design tools that actually use this information to help guide the design from architectural planning though signoff and silicon validation.
We are indeed getting away from ad hoc power-design methods, said Wang. He pointed out three Cadence examples. The first is power exploration through Cadence Chip Planning Solutions. (See the Webinar here.) The second example is power estimation and optimization for C-based designs using the Cadence C-to-silicon compiler, which generates the needed power-intent files using CPF, the Common Power Format standardized by Si2. The third example is power analysis during accelerated RTL simulation using the Cadence Palladium XP Verification Computing Platform. In all three examples, a common power-intent file format such as CPF or UPF is required for communicating power intent across tools.