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 and tapeout).
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 last-minute problems.
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.
Also, clocks 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.
4. Don't 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.
Library 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.
5. Plan 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!
