By Ann Steffora Mutschler

Each passing design node shrinks electronic designs ever smaller and more complex, which has made power management a critical design priority – even in the synthesis step in the design flow.

Synthesis has always been an integral part of the design process, particularly at the RTL level. But as chip design has become more complicated, the need to raise the process up a level of abstraction into high-level synthesis also has started gaining traction. What’s new is the inclusion of power management in both steps.

“Just like closing on timing or closing on area, closing on power is a responsibility of the synthesis tool including a high-level synthesis tool,” said Thomas Bollaert, product marketing manager for Catapult C at Mentor Graphics Corp. “Low power is becoming increasingly important on the designer’s radar screen and this is why they are asking more of the synthesis tool when it comes to low power.”

High-level synthesis can now be power-aware. While there are certain widely-adopted low-power techniques – such as clock gating, which is critical to understanding how much dynamic power can be saved – that designers typically use and implement when doing manual RTL coding, these can take a lot of time to do by hand and can be error-prone. High-level synthesis has the potential of making the analysis and the transformation automatically on behalf of the designer thereby generating much more power-efficient designs.

Gal Hasson, senior director of marketing for synthesis, power and test automation at Synopsys, said this is all about time to results. “If you start optimizing as soon as you start synthesis you end up with better results. For many years customers have been doing MCMM (multi-corner, multi-mode) in place-and-route only. When that is started in synthesis, better results are achieved. Power can no longer be an afterthought.”

Another key to making sure the best results are reached is a tight interaction between synthesis and place-and-route. “When you’re doing a lot of low-power design, you’re doing a lot of clock gating, or you’ve got physical considerations… If all you’re doing is thinking about low-power on the RTL side or the synthesis side and then you throw it over the wall to a totally different tool or totally different group, a lot of the optimizations that you planned in the RTL might not work out,” said Rob Knoth, senior product manager at Magma Design Automation.

While the majority of semiconductor designers are seriously looking at power, they are also trying to figure out what they can do to manage it in the context of their overall design goals, said Jack Erickson, a member of Cadence Design Systems’ Encounter Digital Implementation marketing group. There are plenty of techniques available today for minimizing power, but ultimately designers have goals in terms of meeting a performance spec, a die size and achieving time-to-market, so it comes down to how they manage all of these things and get their chips out the door, he said.

In response to this, in Cadence’s synthesis tool, as with most synthesis tools on the market today, power is not a separate tool or even a separate step within the tool. “When you look at power versus performance, they trade off versus each other orthogonally, and we don’t want our customers to try to have to manage that manually because they’ll never get their chip out the door in time,” said Erickson. “So we built power awareness in.” Cadence includes the notion of cost functions so that when logic is structured it is done so for performance and using cost functions such as area, leakage power and dynamic power. As a result, everything is considered simultaneously as the logic is being built.

To address leading-edge design concerns, Mentor’s Bollaert said customers are now asking for dynamic voltage frequency scaling. That allows a system to use a different voltage or clock frequency and slow down a design so it consumes less power. As power consumption is a function of frequency and a function of voltage squared, if the frequency is reduced, the voltage is lowered, and this can reduce power consumption.

“Doing this is simple when you look at the math, but doing this in hardware is actually very complicated because the proper intelligence is needed in the system to determine when to slow down the design, when to slow down the clock, and when to reduce the voltage. In order to make an intelligent decision, sufficient information about what each of the subsystems are doing and so forth is also needed. It truly requires designing up front for dynamic voltage and frequency scaling, and it also requires fine-tuning intelligence on when to drive the right frequency and voltage. This is truly an advanced low-power design technique. Few are doing it, some are exploring it, and many would like to be able to do it,” he said.

ST-Ericsson used Mentor’s previous-generation Catapult C low-power technology to reduce the area of IP by approximately 30%, according to ST-Ericsson. With new capabilities, Mentor claims a 70% reduction in power consumption for a different customer using Catapult’s clock gating capabilities.

Magma’s Knoth is hearing the same kinds of demands from customers. From the synthesis perspective, making this happen requires a much more robust and multi-mode, multi-corner infrastructure, which is something that more synthesis tools have started doing, he said.

Going from one voltage domain to another requires a lot of extra logic such as level shifters and isolation cells. Knoth said Magma’s synthesis tool is able to consider that extra logic ahead of time, which is significant because those things take up a lot of area, and are typically slow.

“Level shifters and buffers are very slow cells and when Magma’s tool reads in the UPF or CPF, as you are synthesizing those paths, it will allow you to understand the timing and power impacts of all that extra logic,” he explained. “What users are really looking for is higher-level optimization in the RTL for power as well as better verification, because as you’re doing all these complex clock gating or higher-level RTL optimizations you are changing the logic. If you can’t verify it easily, no one is going to tape it out.”

While the industry clearly agrees that power modeling is a necessity for next-generation semiconductor design at the transaction level, what is lacking is a standard way to exchange power models. Low-Power Design talked with David Hathaway, Senior Technical Staff Member at IBM Electronic Design Automation and Nagu Dhanwada, Senior R&D Engineer and Team Lead for Chip Level Power Analysis Tools in the Electronic Design Automation group of IBM’s Systems and Technology Division to discuss power-aware design and power modeling.

By Ann Steffora Mutschler

LPD: What are the most critical issues you are dealing with in terms of low power design?

David Hathaway: In addition to what we are doing here, both Nagu and I are involved with the Si2 Low Power Coalition. I am the Chair of the Technical Steering Group, and Nagu was Chair of the Flows group (which is now on hiatus) where he worked with Jerry Frenkil at Sequence Design. Both of us work in the Modeling Working Group.

One of the key things that is very important in power-aware design (and I hate the term ‘low-power design’ because IBM is designing some servers that use a lot of power and it is very critical to be power-aware and to minimize that power as much as you can, but you can’t quite call them ‘low power’) is that the largest opportunities one has for reducing power are really early in the design phase at the architectural level when one is doing high-level design. I think it is important, therefore, that tools and modeling techniques and modeling languages be able to support making design decisions and doing design analysis and estimation, and what-ifs, in the design phase.

If you talk to people in the industry you’ll find that most people do that, but they do it off on the side in spreadsheets and things they’ve cobbled together themselves. One of the key things we are trying to do with the Low Power Coalition with the Modeling Working Group is to extend existing standards so that they can be useful at these higher levels of design.

LPD: Are you making progress there? What’s the current work like?

Hathaway: It’s always slow when everyone who is involved has a day job and is also working with the coalition. But we have come to some agreement on some of the key issues – not all of them certainly—but some things that we think are important like being able to support non-mutually exclusive power states in models, and having somewhat more flexible ways of parameterizing power models than are available within the Liberty spec.

LPD: To make the shift to architectural level design, what kinds of changes need to happen within design groups?

Hathaway: I think a lot of them have done it, even informally. One of the important things is to try to connect the early design phase to the late design phase. You’ll find that in a lot of cases it’s done with different tools. You transcribe things from a spread sheet, for instance, that you use from early on to the later design. But uou may not keep your early design estimation spreadsheet up to date so you end up with disconnects. Anyone who is doing power-aware design is already thinking about these things. It’s just difficult to do it very formally and it’s difficult to do very much analysis. Nagu has done some work in the past in terms of doing power modeling for Power Architecture, so he has more experience with doing that at a high level.

Nagu Dhanwada: It’s also target-design-dependent to a large extent. When you are going through a typical microprocessor-based methodology where you have previous generations, there are two things to consider. One is the kind of design you are dealing with. The second is the engagement model, specifically, when you are doing some sort of an ASIC for someone else who is going to consume it and who owns the applications side of things. There you are kind of limited in the applications you get in order to really optimize things and you don’t have that much control over what you are optimizing.

On the other hand, when you are doing more of a microprocessor base where a lot of it is derived from earlier generations you have control over the stack, which includes learning on it, but a lot of the methodology is fixed because you are coming with an n+1 generation design.

At least in the space in between, just as IBM licenses the Power Architecture, we try to promote the Power Architecture. With consortiums like Power.org you are kind of sticking together a design using existing IP, which is more of a bus-centric view. So there you have these early models [either internal or licensed] and along with it, we put in high-level power models to go along with these ESL models. Maybe 3 or 4 years back, when TLM was not a standard and there were no standard APIs and such, we were building on some initial models. Tying in a power model to a transaction level functional model was kind of ad-hoc. That was the approach we took when we were initially going ahead. Now, in the context of what David was mentioning about the whole modeling committee and such, where we started to work on it, that kind of started – even the whole notion of the modeling—from discussions Jerry (Frenkil of Sequence Design) and I had in the Flows Work Group (of Si2) where we were saying, ‘We are putting these power-aware flows together starting from ESL. Now, do we want a different kind of a power model for different pieces of IP or can we try to come up with a power model that can span across different levels of abstraction?’ That’s how the Modeling Work Group got started and why David came up with issues about the need for non-mutually-exclusive states. Those are initial things that came out of the working group.

At an early level, if you are really talking more of targeting the consumer electronics space where a lot of design is done with these pre-defined IP blocks and there are emerging standards at the ES level like TLM, I think it’s the right time to also formalize the power modeling aspect and hopefully extend some of the existing formats – like Liberty – to move it to the higher levels and make sure you can use those even at the ES level. It’s more timely now than before because on the functional modeling side, things have crystallized a lot – there are a lot more standards out there.

LPD: How long do you think it will take for the industry to decide on how to formalize power modeling?

Dhanwada: We’ve been doing things like TLM. It’s not TLM, but any processor designer at any company has these early performance models. Like power models, these performance models are typically at some point a spreadsheet. Later on they take their form of executable models. They might not be in System C but they are basically C with threads, and you model your whole architecture way before anything is out there. You also have proprietary simulators. There have been discussions on how you make such proprietary things talk with existing languages, like System C models. We’ve done some work on this—making these talk with System C and TLM, and what it takes and how you can use these models in a bigger context. Those performance models have always existed but we are still at the beginnings of the formalism, or the extensions to existing models, which are not necessarily tied to any language. For someone to be able to use these models there would be some mechanics needed.

Hathaway: I think there are three things that are important considerations as we start talking about introducing the formalism into this. First, we want some separation of concerns. What Nagu described was a situation in which the power modeling was embedded in the performance models. There wasn’t a clean separation of the power model from the simulation model and this is what people often do when they’re trying to do something very quickly – they push everything together. We would like to have separation of concerns because there are more and more things that people are interested in at the high level and you need some modularity.

Second, you need some continuity in the design. What people have typically done (and this is something that came out of the Flows group that Nagu was chairing) is you create your high-level model, get some answers. Then you sort of set it aside and start over from scratch at the lower level, and build something while looking at what you did before and hope you’re building something that matches it. There is no formalism for guaranteeing continuity. As I evolve one piece of my design, having a mix of high level and low level is difficult.

The third thing to realize about power, which is different from things like timing, is that it is used in many different ways. With delay models the rule is you go in, you get a delay. Maybe it is a statistical delay, maybe it’s not – there are things about what parameters are. Basically, you are saying there is a ‘from’ node and there’s a ‘to’ node. How long does it take for a signal to get from point A to point B? For power, you may be concerned about average power; you may be concerned about average power over short periods of time, over long periods of time that drive electromigration. You may be concerned about very local power. You may be concerned about electromigration of a particular via or wire. You may be concerned about overall chip power. Or you may be concerned about waveforms because there is transient A/C power grid noise that you have to worry about so you don’t just care about the power, you care about what the power waveform is.

A benefit, when you’re looking at power that we don’t always exploit in our current models, is that power is much more separable than delay. You can to a very large extent say, ‘This piece of my power came from leakage; this piece of my power came from A/C switching,’ and I can separate those concerns. It is useful to be able to give reports back to the user that gives them the sensitivities to these various things because the power is separable. We’d like to take advantage of that.

When you are talking about the architectural level, optimizing power – although there are some tools that may be able to help you a little – you’re basically talking about a designer decision process and unlike timing where there are millions of billions of paths, and you can’t possibly close them manually, you’re making high level decisions in power and its very important to give the designer feedback so that they can do their own pareto analysis and determine where to get the biggest bang for their buck. To do that, you need to understand the sensitivities.

LPD: Would you like there to be external tools that could be used internally?

Hathaway: I think the fact that we can’t do the things our designers want to do with external tools gives us a competitive advantage by doing analysis with these internal tools. I don’t think it’s the tools per se; I think it’s that we have certain capabilities. Particularly in our ASIC library, we have partnerships with other companies and we would like to be able to exchange IP more easily. We would like to be able to bring in IP that has power models, that has these properties that we think are important. For those reasons, we think it is very important and would be very useful to us to have industry standards, whether we are using our own tools or using vendor tools, so that we could at least have easier interchange and compatibility of IP.