Best Practice for RTL Power Design for Mobile

Mobile devices are taking over the world. If you want lots of graphs and data then look at Mary Meeker’s presentation that I blogged about earlier this week. The graph on the right is just one datapoint, showing that mobile access to the internet is probably up to about 15% now from a standing start 5 years ago.

Of course, one obvious thing about mobile devices is that they run on batteries. Although there is slow steady improvement in battery technology, nobody is predicting any imminent breakthrough so if we want our batteries to last then we have to do that by getting the power consumed in the SoCs in the phone/tablet down. Or at the very least, not letting in increase. For very high volume devices there are some big discontinuous changes on the horizon such as 20nm FinFET or FD-SOI, both of which have considerably lower power than the previous generation of 28nm planar (which doesn’t have great leakage characteristics).

So when do you decide to do power analysis? One answer is all the time. But realistically, above the RTL level the design is just a block diagram without any detail for any blocks that don’t yet exist (IP blocks may be well-characterized). Below the RTL level, gates or even lower, there is very accurate data available (especially post-layout) but it is too late to make anything other than minimal changes. So like Goldilock’s porridge, RTL is not too hot and not too cold, it is just right.

Any power analysis, except the most coarse, requires vectors that stimulate the design in a “typical” way so that you can measure the power. Also, since you want to get a good power network designed early, you also need to find corner-case vectors that have the big swings in current that might drain the decaps or cause noise spikes or cause unacceptable voltage droop. So out of perhaps millions of available vectors, only a tiny percentage are needed to get good analysis done.

Design is not a static process. So once a strategy for keeping power under control has been agreed, regressions are necessary to make sure that as the design progresses that no surprises occur and suddenly increase the power. It is always easier to fix a bad change to a design just after it has been made rather than when you are about to tapeout.

So the basic flow is to start by making design tradeoffs. Next, power vectors need to be profiled in the various different operating modes that the design might be in (playing mp3, transmitting, receiving, watching video…). The power can then be checked against the budges and any hotspots identified. These can then be prioritized, deciding which anomalies are likely to have the biggest “bang for the buck” when fixed. Using automated tools, perhaps along with some manual and even embedded software work, the power can then be further optimized. And finally regressions created to make sure that the hard-won reductions don’t suddenly get lost.

Apache (you know they are a subsidiary of ANSYS don’t you!) have an webcast on best practice for RTL power. It is presented by Preeti Gupta who is director or RTL produt management. Here is the link for the webcast. It is 30 minutes long.