So you're about to start your first low power design. Or
second, third, or fourth. As with many tapeouts, you know that with today's
tight market windows, most likely the project will go off with a sprinting
start (architectural planning), followed by an endurance test (designing and
implementing), then a final mad dash towards the finish line (signoff closure
First, the bad news - given the complexities of today's
design requirements and the swiftness in which the technology market moves, the
project crunch noted above is still going to happen. The good news? If you're
implementing a low power design, there are a few things you could do to reduce
These tips apply mostly to power-domain based designs that
use techniques such as power shutoff (PSO), multiple supply voltages (MSV), and
dynamic voltage-frequency scaling (DVFS). However, some apply to non-power
domain designs too.
1. Check your low power library availability! If you
are well into the physical optimization stage of your design flow, you're counting
on doing always-on net optimization, then realize "uh oh, I have no always-on
buffers," that translates to at least 1-2 weeks of schedule delay. Obviously
you'd want to check for library requirements early in the project, but
sometimes for low power designs the requirements aren't that obvious. So here's
a short list of the priorities:
If you are doing an MSV or DVFS design, check
for the availability of multiple supply voltage-characterized libraries. Sure,
you could use k-factors to extrapolate delay characteristics based on different
voltages, but that's a very risky practice due to inaccuracies.
Check for level shifters, isolation cells, power
switches (headers of footers, depending on which on you are planning to use),
and of course, always-on buffers and state retention cells for PSO designs if
you plan on using them.
2. Plan to use at
least RTL simulation vectors for your power analysis. Vector-less power
analysis is okay for estimation purposes, but at some point you'll have to
switch to using vectors. Now, getting gate-level activity vectors for your
design might be a bit hard since that only comes after doing gate-level
simulation. But, RTL simulation vectors are typically available much earlier.
The old saying
"garbage in, garbage out" applies here. The quality of your power analysis is
completely dependent on the quality of the activity vectors you are feeding it.
If that doesn't scare you enough, think about where this information is used:
besides determining whether your design will meet power consumption specs and
also fit within the packaging selected for your design, this information is
also used as a basis for measuring dynamic and static IR drop, electromigration
and other electrical problems that might come back and bite you if not taken
care of early.
3. Try to
test out your clock trees before finalizing your floorplan. This is helpful
especially for power domain based designs. As we know, power domain definitions
place restrictions on your floorplan in terms of placement, optimization and
other factors. If, for example, your clock tree root starts in a power domain
that's physically far away from your PLL, you can be sure that there will be a
lot of buffers added in between, which means a much higher latency.
that exit one power domain and enter another power domain might be affected by
the power domain layout in terms of skew and transition time. So, by doing at
least a trial clock tree synthesis run before you finalize your floorplan, you
should be able to catch problems like this early on, and fix it before your
floorplan is finalized.
over-constrain (too much) on IR drop requirements. Let's face it: the
reality is we always over-constrain our designs. We over-constrain on timing to
leave us some margin towards the signoff stage, and we over-constrain on IR
drop so that we'll be able to meet the IR drop requirements of the library even
if we take into account some variation between implementation and signoff. The
main reason for IR drop requirements is that library cell performance degrades
in accordance to IR drop, so too much IR drop may lead to the design not
meeting timing even though STA thinks it does.
providers usually build in a little margin when specifying IR drop
requirements, and it's perfectly normal for designers to add another layer of
margin to that when implementing. The problem comes when expectations are
unrealistic for a given design. For power shutoff designs, power switches
usually cause some additional IR drop to that power domain. One way to decrease
IR drop is to increase the number of power switch cells, but that's a
double-edged sword because additional power switches lead to more area and more
leakage power, which will ultimately negate the effect of having power switches
in the first place. So, you can see how we could potentially shoot ourselves in
the foot if we specify an unrealistic IR drop constraint.
out your high fanout always-on nets. Planning out high fanout nets in
general is a good practice for any design, but this applies even more to power
shutoff designs if they have always-on high-fanout nets (hint - they usually
do). Power switch sleep enable nets, SRPG sleep nets, and others would fall
into this category. If you are planning to tap from nearby always-on power
supplies to power the secondary power pins of the buffers for those nets,
it's best that there actually is a nearby always-on power net available.
With that said, I hope this has
been useful to all the folks out there designing for low power. I'm aware that
this is not an all-inclusive list. Would anyone else like to share any pointers
on low power implementation? Voice your comment below!
By the way, for those of you who
found this blog article interesting, we have a webinar on low power coming up Sept. 9. Details are here: