Defining Power Intent

By Ann Steffora Mutschler
Designing power-sensitive SoCs has never been more challenging given the tremendous demand for power efficiency in applications ranging from smart phones to servers inside data centers. That makes describing the power control architecture of a chip through power intent essential.

Specifically, explained Will Ruby, senior director of product engineering and applications at Apache Design Solutions, “power intent describes the partitioning of a design into power domains. In some cases those are active power domains that are being turned on and turned off. In some cases they are simply voltage domains, which is different supply voltages used in the same chip.”

Power intent also sometimes describes the control signals that are used to control these power domains. It describes special cells that are required to implement such a design such as level shifters, retention cells and so on, various rules that the architecture of the chip and the usage of these cells should contain—things like ‘this domain is always on,’ or ‘this domain is off under certain conditions,’ or ‘this particular cell is used between these domains.’

While this sounds straightforward, when it comes to an abstraction level higher than RT, it is a different story.

Cary Chin, director of technical marketing for Synopsys’ low power solutions group doesn’t believe the concept of power intent is well defined today at the transaction or systems software or applications software level. “The best and most common language that we can talk about spans from hardware implementation, which is where we are used to operating, all the way up through transaction level modeling and up into the software domain, is kind of this piece of power, which is kind of like ‘activity.’ To me ‘activity’ is a common thing that we can at least talk about across all of these domains because power depends on specific voltages, it depends a lot on a particular implementation, it has dependencies on physical implementation, proximity, packaging – all of these technologies that you really aren’t thinking about or don’t necessarily have visibility into at the system or at the application software level.”

Still, there are concepts that permeate all those levels that are related to activity.

“When we look at software development/software testing, we do think about this idea of things that change in software, and that’s pretty analogous to the kinds of things we think about in hardware,” he said. “Certainly, activity in hardware is pretty well defined. We can define transitions—zero-to-one, or one-to-zero transitions—on any of the logic we have in our chip. Those things are very well defined and, in fact, those are the transitions that we use to compute power in our power analysis tools. So all the way up to the software level we have this concept, when we look at software development and software quality, of what things change. What was the path that when I give a particular example of inputs to my software, where does that actually go, and what is the path that it takes through the software development? At a very high level, I believe that that’s one of the common things that we’re going to exploit, this idea of activity.”

In addition, Josefina Hobbs, technical solutions architect in Synopsys’ low power solutions group pointed out that in terms of accuracy, when you’re doing things at the system level you don’t have all the technology information that will give you the accurate matching to silicon, but if you raise it up a level and look at activity you can accurately get an idea of what parts of the chip or even what parts of the system are on or off, or doing something or not doing something. You have a concept of activity states – maybe not a power state per se – but activity states.

In most of today’s designs, however, power intent allows the designer to have control over a portion of the chip where they are either intending to power it off completely or run that section of the design at different voltages and typically different clock frequencies as well, according to Barry Pangrle, solutions architect at Mentor Graphics.

“In a lot of chips, the power budget is going to be dependent on the application it is going into. If you are looking at an SoC that is going into a cell phone, for example, you look at the ITRS roadmap for 2009. Even if you go back a couple of years, basically for a chip like that they are saying the hard requirement is going to be about a watt and there are a couple of things driving that. One is the size of the battery and how much energy you can put in a battery and the customers’ expectation or battery lifetime. The other is heat dissipation. You don’t want a toaster up next to your ear, so even if the battery could supply it you’re going to be limited,” he said.

These are not small issues. For some design teams, the larger part of the bill of materials cost is actually in the package. Because they have to operate in environments where they can’t put a fan or any type of active cooling, it is all passive cooling. That has implications for the packaging cost. “If the chip itself starts to produce too much heat they have to go into a more expensive package, and that can actually take them right out of the market,” Pangrle noted.

From a starting point, a lot of what engineers have to work with is a whole system thing as well, he continued. “Typically there is some board that is going into some product,” he said. The board is going to have a power budget and the chip is going to get some allocation of what that whole board is. And presumably, someone has done some type of thermal analysis at least roughly at the beginning to figure out how much thermal power can we deal with being dissipated and going from there. As more voltage domains are created, the chip complexity goes up along with the overall design cost.”

Specifying power intent
Today, power intent is captured with the UPF (IEEE P1801) or Common Power Format (CPF) languages, although some companies (Apache is one) use their own UPF/CPF-compatible language.

The language is then captured in a side (text) file, explained Qi Wang, head of solutions marketing at Cadence Design Systems. “This approach allows legacy IP, which may not be power optimized, to be reused in a system that is power optimized and so as not to inadvertently change the functionality because designers do not want to have to go back to the original RTL code to make changes.”

Another motivation to use this approach is more subtle: low-power methodology. “This helps to make sure that what you have implemented is also following the spec,” he said. One step further is to make sure there is a verification methodology to verify that what is implemented is what had been asked for in the RTL design stage. This means mechanism is needed to carry on this power intent across the flow and not just in the RTL. “That is what the RTL approach of the power intent cannot offer – you have to put it some other place – and that is why it is in the side file so that it can be used by multiple tools from RTL to GDSII.”

An added dimension of power intent looks not just at the architecture and structure of the design, but also examines power consumption of the design itself. “This is like a different dimension wherein these power intent formats, there is a way to specify for example maximum power per block and something that can be checked against and so on, but it’s only essentially at the block level,” said Ruby. “One of the things that we are exploring is how to enable our customers to be able to track wasted power in their designs under certain conditions and be able to put limits on wasted power and things like that. So there are other dimensions to power intent such as this. What customers are starting to do with our technology is put together what we call ‘power regressions.’ In the past and continuing today, there has been the notion of functional regressions – simulations that are being done to exercise the design and check for functionality. Power regressions are kind of similar in the sense that they also are simulation based; the analysis though is a little bit different.”

The goal of power regressions is to simply track power consumption as the design is evolving, as functional bug fixes are being done, as other things are being done to the design, and make sure that the power consumption doesn’t really go off track.

“The idea is that design teams are now starting to track power very diligently because if they see power go up and they don’t catch it in time, that type of a power problem doesn’t somehow magically fix itself as part of synthesis or physical design. If you have a power bug, it doesn’t magically disappear,” Ruby concluded.