Experts At The Table: The Power Problem

Low-Power Engineering sat down to discuss a broad swath of power issues with Vic Kulkarni, general manager and senior vice president of the RTL business unit, Apache Design Solutions; Pete Hardee, solutions marketing manager at Cadence; Bernard Murphy, chief technology officer at Atrenta, and Bhavna Agrawal, manager of circuit design automation at IBM. What follows are excerpts of that conversation.

LPE: Can the power problem be solved in advanced designs or are we headed for a brick wall?
Murphy: What we’re dealing with is not a point problem. It extends all the way from application-level software design down into the implementation. It’s a stack.
Agrawal: When people were worrying about performance it was very easy to separate out instructions per cycle and cycles per second. You could optimize each of these and debug the optimized system. Power hasn’t had any such separation. People have tried look for some separation but it’s a very hard problem. That’s why the problem persists. Ten years ago people were saying power is very important, and since then some progress has been made. But we are looking for function in a power envelope all over the place, not just in a single application.
Murphy: The cell phone industry has been at the forefront of this, and one cell phone engineer told me they put a lot of functionality into the chips to do all kinds of sophisticated power-up, power-down tricks. The expectation is these knobs will be turned by the people who develop applications on top of these chips, but he said the big surprise is that no one takes advantage of those knobs because they don’t know how to. They’re lost bridging from the application to the power model of that piece of silicon.
Kulkarni: At last count there were about 22 different techniques, from system to microarchitecture to logical and physical for reducing power, analyzing power and managing power. It’s now come down to design for power. There is no single silver bullet. It comes down to dynamic power and static power, and simply managing those two equations across all levels of abstraction. But each decision you make has tradeoffs, so these 22 different techniques we’ve studied using area, timing and noise have an impact. That’s why no one has been able to solve this to date. If you look at the power grid or power delivery network, it becomes critical at all levels, not just the highest level. How you deliver that on the chip and around the chip involves tradeoffs for electromigration and electromagnetic interference. They all get impacted by microarchitectural decisions.
Hardee: A lot of these techniques have been around a long time, but what we saw at 45nm and 40nm is that leakage took over from dynamic power as being the biggest problem. We’re seeing a different emphasis on those 22 techniques that Vic talked about. The best ways to manage leakage involve shutting off as much of the system as you can. That has to be done under software control. But we’re also starting to see some physical limits as you go further down the process nodes about what you can do with leakage. The leakage is continuing to increase and the supply voltage is getting closer to the threshold voltage. There is some life left in bulk CMOS, but at 22nm people are starting to think about new approaches like SOI. The tradeoffs are not just timing vs. power. There are also cost tradeoffs for yield.

LPE: We’re hearing more about not just SOI, but fully depleted SOI. But how does all of this affect things like power delivery?
Agrawal: Suppose you have an electromigration problem in your power wire. What do you do? Do you need different materials for your wire? Can designers do something with the layout. If you move the wire, does the problem become bigger. It becomes a problem from the gate level to memory to the power level to the system-performance level. To get all these people at the same table talking the same language is not easy. People call it the kiss of death because it’s so hard, but the time has come where people have to do these things. It’s necessary.

LPE: Will this type of approach become mainstream, though?
Murphy: Everyone believes the biggest place you affect power is at the application software level. It’s going to be pretty interesting to watch Apple over the next few years. The iPhone has not been famous for its low power characteristics, but they have an advantage over the merchant market because they own the whole thing.
Hardee: Apple got people complaining about battery life after an OS revision. That meant they were back to the wrong defaults.
Kulkarni: There are many problems to solve. In the stimulus management, how do you measure power? When people generate their vectors those are not necessarily high-power-consuming vectors. With thousands of gates a clock can consume a lot of power. And memory-based designs can consumer a lot of power. The selection of right vectors will affect the power delivery metrics. Some vectors involve the package and the PCB, but when you are creating your stimulus that’s typically used for functional verification, not for power verification. The new challenge is what we have dubbed power pattern generation. That’s becoming important in most of the tough system designs like mobile phones—creating the right stimulus to drive the right power combinations. That may be multimode vs. high power-consuming vectors. If you create a functional vector set you need to select the right vector. We are finding convenient ways to live in our comfort zone, but finding the right vector is critical.
Agrawal: That’s the big difference between timing and power. Timing has been studied for a lot longer than power. People do static timing analysis—best case, worst case—and come up with one number. Power is not one number. There is different power for functional and IR and EM analysis. There is different power for di/dt (current change) and for battery life. So my power analysis has to be componentized so that given a power model I can do analysis at all these different application power corners for the same chip. That’s where patterns and switch factors come in.

LPE: But there aren’t many companies outside of IBM and Intel doing this, right?
Agrawal: That is correct. Because there is nothing available we’ve had to do it ourselves. It’s not because we love to do it.
Hardee: There are a number of people that need to work on this problem. As we’re getting the convergence of applications onto all kinds of devices, there isn’t one system mode where you can check everything. There are many different modes for just power alone. If I’m worried about leakage I’ve got to look at some modes that are shutting off a lot of the system as well as the modes where there is a lot going on. My peak mode may be in a totally different system mode to the peak mode that’s broad enough to give me a thermal problem. There are different kinds of peaks you need to look for. And with battery life, it isn’t power that you’re worried about. It’s energy. It’s the integration under the curve. You’ve got to run an awful lot of vectors for that. The other power measurement issue we’re all familiar with is accurate characterization, and the common wisdom is you need that late in the flow to be able to get a power measurement. Where people are failing is by having the wrong system activity.

LPE: With the future headed firmly toward multiple cores, will software written for specific cores or lots of cores that work as a generalized platform for whatever processing is needed?
Murphy: There’s no clear answer to that today. Almost invariably you have a housekeeping core, which is going to do stuff like boot management and configuration management. That may also be the center of where you manage your power. But if you look at any cell phone, you have DSPs performing all kinds of functions. It’s not clear yet how you divide up the software between the cores. What is clearer today is how you turn on and off all the peripherals like video and audio.
Agrawal: You design power switches and functionality that no one takes advantage of. At some point you can envision a chip with high power and single-thread performance, so you shut off everything else. But eEven though your whole chip doesn’t heat up, you may have a problem locally. So software needs to co-designed with the hardware, and today we don’t really do that.
Hardee: Using a general-purpose processor is not power-efficient. Using dedicated cores or programmable accelerators is better. And putting dedicated functions into hardware rather than running them in software may be the most efficient way.