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.”

By Ed Sperling
Low-Power Engineering sat down to discuss rising complexity and its effects on verification with Barry Pangrle, solutions architect for low power design and verification at Mentor Graphics; Tom Borgstrom, director of solutions marketing at Synopsys; Lauro Rizzatti, vice president of worldwide marketing at EVE, and Prakash Narain, president and CEO Real Intent. What follows are excerpts of that conversation.

LPE: When do you verify closer to the metal and when do you move to a higher level of abstraction?
Pangrle: The higher level of abstraction is the wave of the future. It’s where things are headed.
Borgstrom: It’s been the wave of the future for the past 10 years, though.
Pangrle: But it is different the time. We’re seeing traction with customers and the blocks they’re using it with, and we’re hearing from them, ‘You know, we couldn’t have done it at this time if we didn’t have this tool.’ That’s different. There’s an efficiency that’s only going to ramp from here. But at the same time, we’re modeling in C. If the architects have the same hole with what they’re using and the same way they’re testing it, and that’s what you’re going to measure your RTL against, how are you going to catch a problem? The hole is in the model.
Narain: No, because when the verification engineer compares a mismatch between the RTL and a reference C model, then you can find errors in the reference model.
Pangrle: You can always find errors later in the process. People still check at the gate level and find errors in RTL.
Rizzatti: Exactly. Nvidia is still emulating at the gate level with hundreds of millions of gates.
Pangrle: Doing this higher-level stuff doesn’t preclude doing things at the gate level. But it does give you a higher level of confidence that if I’m taking C and using that to generate RTL, then hopefully I won’t have as many errors.

LPE: When do you know when you need to look at the higher level or at the RTL level?
Borgstrom: It’s really a continuum. Every project starts out as a concept, so you do some high-level modeling and algorithm development. Then it follows the classic ‘V diagram’ development where you go from that high level and make all the components. When you get down to that IP or block level, you’re doing very detailed verification, simulation and formal analysis. Then when you get all those blocks developed you start integrating them and do full chip verification involving simulation and hardware-software co-verification on a hardware-assisted verification platform. You eventually get up to full system integration where you’re prototyping with external interfaces. At each phase of the process you’re using a different set of tools to find a different set of bugs.
Narain: There’s top-level activity and then design starts in a distributed manner. Designers start implementing various pieces of a design based upon a spec, and then it comes together. So the design starts of as blocks, then it goes to clusters, and then to a full chip, and at every point you have a chance to use verification. The big questions are what is the cost, how much investment you’re going to make and what is the return. Typically block-level verification is compromised because there are too many testbenches to develop. People tend to do simulation more at the cluster and full-chip level. At every point in time you apply the cheapest technology. A lot of blocks can use formal verification. When you get to clusters, you need more sophisticated techniques. At full-chip level, you start getting into emulation.

LPE: Analog is separate, as well, right?
Narain: Yes, analog is different and you use your own techniques for that.
Borgstrom: There’s a dedicated tool chain for doing custom blocks and custom simulation. The designer and verification engineer are very often the same person. It’s a very close iterative loop. There’s a real need for doing mixed-signal verification once you start integrating the whole SoC with the analog blocks and making sure that analog-digital boundary is behaving correctly, both from a power perspective and a physical connectivity perspective.
Rizzatti: If you have a problem at the higher level of design in C and you don’t catch it, you don’t catch it at the RTL level?
Narain: That’s correct.
Pangrle: But the reference is the same.
Narain: No, what you’re saying is that you take the C reference model and automatically derive RTL from it. I’m talking about taking a C model and let the designers independently generate RTL. If you automatically derive RTL you won’t find the errors. If you use a spec and let the designers test against that, then it is conceivable that a bug will be caught.
Pangrle: There is a chance of an RTL to C mismatch. But it’s more likely that will be a problem with how the RTL was implemented. If I have some idea of what I’m looking for—and that’s usually defined by the architect—then I’m more comfortable knowing that what I’ve modeled has been turned directly into RTL. If I hand it over to an engineer to figure out my intent and then he goes off and does his own thing, then there’s even more likelihood of a mismatch. The mismatch will be more likely from the translation.
Narain: If you compromise on independence of fundamentals of the checking, then you’re compromising on the integrity of the verification.
Pangrle: This is like having multiple votes. You should have three independent design teams?
Narain: If you can afford it.
Borgstrom: It’s clear that this high-level design and verification flow is relatively new and controversial. But it does show a lot of promise.

LPE: Let’s swap topics. Software is becoming more complicated and so are power issues involving islands and various modes. What does that do to the verification process?
Rizzatti: It’s a nightmare.
Borgstrom: It’s a lot more complicated. The data we have shows that at about the 65nm node, average design team size is evenly split between hardware and software. As we get into smaller and smaller geometries we’re starting to see software-driven architectures where a lot of the value of the semiconductor product comes from software delivered along with it. When you have a huge software team waiting for software to come out, that’s not very economical. One thing chip companies are trying to do is figure out how to get their software teams started sooner. One way you do that is to come up with a virtual platform. You come up with a SystemC, TLM-level model of the overarching design even a year before you have silicon and get people writing software against that. As the RTL becomes more mature, you can put that into a hardware-assisted platform like an FPGA rapid prototype and continue your software development running at 10MHz to 30MHz prior to silicon commitment.
Pangrle: We’re seeing similar things in the market. There’s a shift toward software. Anything you can do to help teams get started earlier on software helps close that whole window down in terms of the amount of time they need to get a whole system up and running. We feel that standards help speed up this whole process. Using TLM 2.0 help is all part of the Open SystemC initiative. You also really want to know what the intent is of the design and how you’re going to partition it up, because that has an effect on how you start verifying it. Being able to determine which blocks you want to run at which voltage levels and which ones you’re going to use to create voltage islands—that’s information that gets passed down for verification. If I run everything at a single voltage, then I don’t have to worry about these kinds of issues. But if it makes economic sense to run a block at lower power, then I have all these other things I have to check.
Narain: Control over the design implementation process is a big problem. There is a strong requirement for software to eliminate errors in the implementation.
Rizzatti: The crossing point between hardware and software, according to Handel Jones, was 130nm. The other thing is that you start with virtual prototyping and after that you move to FPGA prototyping. If that were the flow, it would kill emulation. I don’t see that happening and that is not what the large chip makers are doing. There is a very clear moment in the flow where emulation is unique, which is the integration between hardware and software because the FPGA prototyping will not give you any ability to trace bugs. And we see this more and more.

This whitepaper discusses one of the most important power optimization techniques used in Catapult C Synthesis – advanced clock gating optimization and analysis. Electronic System Level (ESL) design methodologies enable power consumption optimization opportunities unreachable for traditional RTL design methods. Learn how Catapult C Synthesis can help you deliver designs with minimum power dissipation using its several power optimization methods and power-aware architecture exploration capabilities. To download the paper, click here.