Start Early, Cover All The Bases

Design for low power always has challenged designers and design tools. You need to have accuracy, because you are estimating implementation-centered parameters, but you need to start early, before implementation, if you are to have any hope of meaningfully reducing power. Sure, you can always play with body-bias, but that is a crude control. Real reductions after architecture always come through intelligent clock and memory gating, options that are simply not realistic after synthesis.

There are some very clever techniques available, based on formal technologies, to find useful gating opportunities beyond those covered by your favorite synthesis tools. But you are challenged again by that accuracy question. Clever though those formal techniques may be, how do you know they will have any meaningful impact on the actual system power? In fact, when you trade off physical design complexity added by the implied gates and wiring over purported power savings, you really have to look to accurate power estimation to draw boundaries. So now you have to put synthesis and gate-level power estimation into the loop. But that really slows down experimentation. It’s accurate, but you won’t be able to try more than a few options in a reasonable time.

The answer here is to have accurate RTL-based power estimation integrated with power reduction. You run power estimation to get a baseline, then run those clever methods to find all possible reduction opportunities, then run estimation again to build a table of differential power savings, from which you can select just those cases that will give you meaningful reduction without over-tasking the physical design team.

But there’s another challenge. If you are up on the latest design methods for low power (and I’m sure you are), you are probably using UPF or CPF to describe power intent. Now you are describing voltage islands, power islands, power state tables and lots of other goodies. But that is going to affect your power estimates. And you’d better make sure that power intent is legal and correctly described while you are at it. So now you need to add to your solution the ability to verify power intent (because that will build logic into your design in implementation) and you need to be able to incorporate that intent into power estimation.

So there you have it. A truly useful solution has to cover RTL power estimation which can correlate with gate-level estimates, advanced techniques to find power saving opportunities, coupled with the same RTL power estimation to grade those opportunities, coupled with power intent comprehension and verification to ensure implementation-stage enhancements are factored into the analysis. Perhaps we should add biasing estimation, but maybe that is a bridge too far.

Atrenta recently presented a webinar on the topic of the three dimensions of RTL power optimization. We discussed these issues in the context of available solutions. If you missed it, the replay will soon be hosted here.