Experts At The Table: Power Budgeting

By Ed Sperling
Low-Power Engineering sat down with Barry Pangrle, solutions architect for low-power design and verification at Mentor Graphics; Cary Chin, director of technical marketing for low-power solutions at Synopsys; Vic Kulkarni, general manager of the RTL business unit at Apache Design Solutions; Matt Klein, principal engineer for power and broadcast applications at Xilinx; and Paul van Besouw, president and CEO of Oasys Design Systems. What follows are excerpts of that conversation.

LPE: Where are the gotchas in design?
Klein: There’s a good Las Vegas analogy for place and route. Even if there’s 50-50 odds, you’ll lose because you don’t have an infinite supply of money. It’s similar with capacitance. You have the same thing with RTL code. You can’t connect to an infinite number of places using the shortest distance. So then you need to make tradeoffs. What is the V(2) and what is the F of this group? Should you allow more capacitance here, or less? You can’t connect to anything in zero time?
Chin: Aside from the obvious V, which is squared, it’s the F that’s important. C is an implementation—a detail—that is impacted by the other variables, but F is the most important. It’s the switching activity. The more understanding you have of that switching activity, the more you can affect how is this thing operating and when is it operating. The biggest problem of being able to start with some budget of power and later being surprised is usually associated with having a bad assumption about F. At a very high level we can understand that. A lot of things we intend to be mostly ‘off’ aren’t quite so ‘off.’ Even though your phone is sleeping, it isn’t quite sleeping. When you move around, accelerometers wake up even though the screen is still black. This is the leakage with a small ‘L.’ It’s not static power. It’s operations that are happening at the device level that aren’t doing anything useful. It’s high-level leakage of power that isn’t computed into the implementation flow because we assume it’s ‘off.’
Klein: We don’t assume it’s going to be off because in the FPGA we don’t have islands where we turn off an entire function.
Chin: But in terms of activity, we’re assuming there’s not going to be any toggling of activity, and therefore no dynamic power.
Klein: In regards to noise, sometimes you can create an algorithm that you didn’t expect to be generating too much noise. But I’ve worked with customers where they’re getting noise and they can’t figure out why. We’ve said, ‘It looks like you’re doing four cycles and then rest and then four cycles and then rest.’ And they are doing that to match rates of blocks. That produces noise, and noise can produce power, as well. Sometimes those require algorithmic readjustments.
Kulkarni: We’re finding that the glue is missing between these areas. As the problems get more complex with Moore’s Law, there’s no ability of architectural designers to talk with SoC designers and IP designers. Sometimes the IP is designed by another company or in another country. And then, finally, there’s the package at the end of the chain, the PCB and the DDRs. DDR4 is going between 1.4 and 1.6GHz, and it’s creating tremendous noise. It’s creating overall power budgeting issues that transcend just the SoC. You have to manage that off-chip.

LPE: That brings up a good point. How much of this is out of your control now as you bring in more third-party IP and software from other vendors?
Van Besouw: Most of the IP that people bring in right now is RTL-based. It’s soft. IP may even go to the system level, as well. But you have to question whether it’s a budgeting issue going from RTL or whether it is knowing how the power consumption will be once you go to silicon. One of the reasons system-level design isn’t everywhere is that it’s not connected to the rest of the design flow. We need to create tools to make that connection. You need to make the right choices at the right time so you can still make a big impact on those variables. That’s the key. It’s more about automation than trying to impose more methodologies around the limited tools we have today. EDA has allowed that, and it has affected innovation.
Kulkarni: It’s our responsibility as a tools vendor to allow cross-domain enablement. How do we connect these static blocks of companies, groups, divisions, or the knowledge base? We need to encapsulate those models—and modeling is an important part of the power budgeting equation. The power models may contain a die model for a power grid, current sources, power profiles and the parasitic capacitances. We need to encapsulate that, along with the right frames that are selected from a stimulus, which can then include IP—including hard IP and hard analog IP—plus RTL that’s configurable. Then you need to create a chip-power-model. The job of a package engineer becomes easier. The job of an IP engineer becomes easier. And the job of an RTL engineer becomes easier. The models are encapsulated in the flows and the tools themselves.
Pangrle: There are certainly challenges there, but it opens up opportunities for everybody here to provide better methodology in tools. There’s also room for improvement in how the IP is being delivered to the customer. There’s a lot more information that can be included with the IP to make everybody’s life easier.
Kulkarni: There has been a lot of work in the functional and timing areas, but power is where those areas were 20 years ago.
Van Besouw: Power is like an afterthought.
Klein: There is some flexibility in FPGAs to alter the power afterwards, but you have to do advanced design in the parts that can’t be altered after the fact such as the process choice, static power, what user functionality you have for power.
Van Besouw: But even configurable approaches have limitations.
Klein: The attitude about timing is different than power. When the timing doesn’t do what it says, the design fails. Nobody will accept that. But if the power is 10% high, the attitude is, ‘Oh well, I didn’t really think I could predict that accurately, anyway.’ With timing if you’re off by 10% it doesn’t work.
Van Besouw: That’s changing for power.
Klein: Yes, it is getting that way.
Chin: On my phone I’m tolerant of dropping calls, and I’m becoming more tolerant of waiting for my phone to do things. But it’s really a problem when it’s out of power. From a mobile device standpoint, that’s like getting the wrong answer on your calculator. Power is the most important thing on a mobile device.

LPE: So how is this changing the design priorities?
Kulkarni: At least 10 companies we talk to all compete on power. They spec it that way.
Klein: We’re seeing the same thing. Our customers are competing with each other on power. They never were before.
Chin: That’s really where the problem is. You know the applications you want to run, but there’s no good way of determining whether it’s 5 watts for one application or 1 watt for another. No one can really tell. We don’t have a hard limit on power. We can’t say if it’s 1.1 watts or 1.2 watts to view a YouTube video, because there are lots of other things going on.
Pangrle: There are lots of other variables to play with. The reason power is becoming more important is that if you’re using a certain package and you know what the cost of that package is, if you’ve blown your power budget and need another more expensive package you may not have a market anymore. You may price yourself out of the market. On the other hand, you can suffer a little on performance to keep your cost within an acceptable range. If you look at applications such as graphics, how accurate do you have to be? If you slip a few frames a second the end user isn’t going to notice.
Van Besouw: It’s like how far can you go on a gallon of gas. It’s not a matter of how fast you can go. Power is the same thing. How long can you talk on your phone?
Chin: And given that battery technology is relatively equal across the vendors, it’s all about power efficiency.