By Ed Sperling
Standards groups are beginning to look at power and other physical effects much more seriously in the wake of the dueling power formats—UPF and CPF—that have caused angst across the design industry.

To put it in perspective, when CPF and UPF were first introduced power was something of an afterthought in design. At 65nm it ceased to be something that could be dealt with later in the design process, and at 28nm it has become an essential part of the architecture. But as battery life, mobility, and energy costs even for plugged-in devices become overriding concerns, power now needs to be considered at full system level, which could mean everything from a rack of servers to an automobile.

Much of this is being driven from the chip level, and in the software that manages chips and interactions between chips. There are at least a half dozen new standards efforts under way or on the drawing board. Most heavily leverage the expertise of chipmaker and where they have encountered or expect to encounter pain in designs, most notably in stacked die or in planar SoCs below 20nm, or from tools vendors that have gained expertise in a specific area.

Si2 currently has one standard in legal review for system-level power modeling. The standard is called “atomic” power modeling, based on the assumption that the model cannot be broken down into smaller pieces, although it can be used at various levels of abstraction.

Also in the works is a standard for co-design, which is one of the most difficult challenges facing design today. While hardware engineers are well versed in how to build an energy-efficient chip, that engineering effort can be wasted if the software running on an SoC isn’t energy-efficient, as well.

“The first step is to get there with the architectural ESL level,” said Steve Schulz, president and CEO of Si2. “Then, we will look at how the software runs and develop a bridge. You will never get the software community to adopt the hardware approach to design. That community is 20 to 30 times larger than hardware engineers and they have their own tool flows. We have to think about a minimally intrusive solution. We’ve called it a bridge to the software world, and if it’s not intrusive then the software teams will use it. Most of them will never understand concurrency and how to get to a GDS II stream, but there are characteristics that are reasonable proxies of the details. You don’t simulate all the code, but you do generate enough discrete choices so everyone can get on the right track for power.”

A first step in that direction is finding data objects that can be passed back and forth between the software and hardware teams. From there a power model will need to be created across both. The power-flow group within Si2 has been reactivated to develop a source for the power model. “The focus this year will be hardware,” said Schulz. “In 2013 we will turn our attention to understand the data objects stored.”

That puts the likely adoption timeframe a of a co-design framework for power in the 2015 time frame—roughly at the 14nm process node and at a time when 2.5D stacking is expected to be mainstream and 3D stacking will become more commonplace.

Stacking effects
“There are two new requirements for design,” said Andrew Yang, president of Apache Design. “The first is a 3D IC flow. The second is an RTL-to-gate power methodology.”

Included in the 3D requirements is the need for multi-die thermal and stress analysis. Yang said the key is the amount of current a design can sustain without failure over time, and it gets worse at advanced nodes and sometimes in stacked configurations because wire handling capability is decreasing, power density is increasing, and electromigration is increasing.

3D IC thermal stress analysis. Memory die is impacted by power distribution of logic die. Source: Apache Design.

“This can be a safety issue,” he said. “You need to make sure the metal topology is handled correctly. Electromigration is affected by heat. The hotter it gets, the less current a metal wire can sustain. The electromigration rules are increasing, which is why GlobalFoundries, Intel and TSMC are all coming up with complex electromigration rules.”

Front to back, back to front
Being able to get a chip out the door at all is a challenge, which is why there are more standards being dictated from the foundries these days. In addition to process variation, continually shrinking geometries is making it harder to obtain adequate yields as quickly as in the past. That has led to more rules for place and route, test, IP, and layered across all of those is power.

“We’re seeing it in the available sizes, speeds, memory and logic cell sizes,” said Chris Rowen, CTO at Tensilica. “That’s what we target—area, power and process compatibilities. Whether that’s stacked or conventional die is affected only subtly. But with die stacking you will see significantly higher bandwidth and less latency, which will have an effect on modeling of the system. It’s not a qualitative change, but it is a quantitative change. It won’t change how one DSP communicates with another, but it will change how DSPs communicate with memory.”

How much of that will be standards promoted by standards bodies versus de facto standards from the largest foundries remains is unknown. Also missing are good open standards for on-chip debug and trace, said Rowen.

ESL standards
One of the most glaring holes in all of this is at the ESL level, where standards for power models are non-existent. While this isn’t a big problem in a single vertically integrated company, it’s a huge problem in a disaggregated supply chain where various companies work on designs—something that will become even more pronounced in stacked die where subsystems at different process geometries need to be integrated with other subsystems.

“What’s missing is something that allows companies to exchange power models, especially for IP-based designs” said Ghislain Kaiser, CEO of Docea Power. “In an ideal flow you would be able to take the IP from the IP suppliers and put together a power model and assess the power impact on the underlying hardware. But you also need to have interoperability between suppliers and customers that goes beyond the semiconductor level. It has to be optimized at each level—the SoC, the chip set, the PCB and above. So there won’t be only one number.”

The accuracy of those power models also will shift throughout the design. At the beginning a model may be only 40% accurate, but at the end it may need to be accurate to plus or minus 5%, Kaiser said.

Other pieces are missing, as well. Kiran Vittal, senior director of product marketing at Atrenta. “Right now, when a designer uses memory they don’t realize the code they are writing is not optimized for power. When you read memory you get a redundant read. The controller code isn’t optimized for memory. And all of that has to be networked, because you may have as many as 2,000 memories in a design. If you do it right you can save about 20% of the memories and the power needed to run them.”

To show just how bad this can get, a large systems house was designing a chip was required to give an early indication of its power budget to the OEM. The OEM used that estimate for calculating its own power budget and came up with a spreadsheet that represented the total design. The problem was that the spreadsheet ultimately was off by 100% in its power estimate, which in turn caused problems with the final device and greatly increased the amount of time it took to successfully bring a product to market.

“A lot of the ESL tools today know performance and area, but they don’t have a clue about power,” said Vittal. “This is fertile ground for innovation.”

By Ann Steffora Mutschler

Back in the early days of semiconductor design engineers could count the number of transistors on their chip with their own two eyes. They designed and worked at the same level of design abstraction when doing the timing analysis. Tools were SPICE-like, maybe abstracted with slightly simpler timing models than the SPICE-level transistor models.

Thanks to Moore’s Law, the number of transistors that can fit on a chip has grown to the billions, which obviously can’t be counted with the naked eye. But they also no longer scale with SPICE. Abstraction has been the way out by providing a higher-level view on the design.

“Clearly, even when I’m at gate level, I know I’m not getting the same accuracy that I would be getting at SPICE level, but if my models are good enough and it is close enough, I’m willing to take that slight hit to be able to do bigger designs,” noted Barry Pangrle, a solutions architect for low-power design at Mentor Graphics. “That’s the progression that we’ve gone from—transistors to gates. Then people were doing schematic capture and everything was gate-level models. Then we went to RTL and we started moving to RTL models. Now we are moving on into system and bigger components and functional blocks. At each level, we’re giving up some measure of accuracy—it’s just not going to be as detailed. It’s not going to be as fine-grained and the hope is though that we have enough information that we can make the decisions at that level of abstraction.”

The abstraction levels in use today were developed over a long period of time. They are well-defined because a huge amount of work was done in terms of both modeling, to make sure we can move between levels, and to ensure there is the appropriate level of detail to accomplish what needs to happen in that level.

“Today, we’ve tuned it and created enough modeling around it so we can get the information that we need out,” said Cary Chin, director of technical marketing for low-power solutions at Synopsys. “But I would say that the model isn’t general enough if we thought of some new use of these connections and voltages and expected it to give us the data that we wanted. Whereas if you did that all in SPICE, it likely would [provide the right data] because that’s one indication of the maturity of the model—whether you can use it for things that weren’t anticipated originally when you built the model.”

At the RTL level engineers synthesize down to a gate-level netlist so that they can bring in their gate level models, Pangrle said, with the hope that based on the information they get from those models, they can create something that’s going to be representative of what they need at the RTL level. “Now we’re looking at going one level beyond that and saying, ‘Okay, at the next level of abstraction what kind of information can we capture here?’ The tricky part is making sure that you still have the level of accuracy that you need to be able to make the types of design decisions that you’re going to rely on that information.”

But these levels of abstraction are not all fun and games. For engineering teams doing low-power designs, there are many challenges moving between these different design abstraction views, the biggest one between the RTL to gate because these two abstraction levels have too many big differences, explained Qi Wang, technical marketing group director for low power and mixed signal at Cadence. “On top of that, there is a lot of handshake of tools between those two levels.”

For example, he said an important aspect of low-power design is to gather activities. RTL simulation is run to collect activity, so all of the signal activity is annotated along with all the signal names. The engineer hopes to re-use that activity at the gate level, but the problem is the name seen at the RTL may not be the name seen at the gate level because the synthesis tool renames the files.

Power formats

In addition to this renaming, a lot of optimization can happen between the RTL and the gate level, which means that some signal may simply optimize out. Another possibility is that the logic may not optimize out but the representation can be changed, Wang said. “On the activity side, this is a flow challenge. The activity file you get for the RTL you hope you can re-use for the gate level, but many times you will find it is very difficult.”

Another kind of difficulty involved is with the power format, no matter what standard is, Wang noted. “The whole idea is that you describe your power intent in another file… If you write a power format file for RTL, which means it will be used for the RTL so all the names you refer to would be the RTL names. Now when you get to the gate level you hope you can use the same RTL level power intent because I want to keep my golden power intent through the design and verification flow.” But this will have the same problem as in the activity file.

To address this formal verification techniques can be used to indicate which RTL register names map to the corresponding flip flop on the netlist with a name-mapping file.

Then on the power intent side, he suggested the easiest way to deal with the renaming issue to have the synthesis tool write out a new power intent file, which automatically will reflect the name changes and the hierarchy ungrouping. When it comes to enabling the flow, however, the power intent written out by the synthesis must be equivalent to the original power intent, which is where power-aware equivalence checking tools are utilized to prove that the new power intent and the old power intent are equivalent.

Twenty years of hard labor

Traditionally, traversing levels of abstraction has been relatively straightforward—it’s just a lot of work. “If you look at the library modeling process that has evolved to go from kind of transistor level to gate level, things are very well defined today,” Chin said. “Libraries are super solid and vendors know how to characterize things even as the technology changes. That’s an example of a level of abstraction that’s pretty mature because over the last three, four or five generations of technology, we haven’t had to make major changes. There have been many, many little extensions and timing models and functionality and things like that but basically since we haven’t changed the fundamental design flow, the models and libraries have stayed pretty much the same, which is great.”

There have been similar advances in synthesis. “If you look at this between RTL and gate level, synthesis has changed a lot over that time, as well, but in general if you couple synthesis with verification tools and formal verification tools, things have actually grown nicely so that we still have very dependable flows that most people are still pretty happy with. You can push the button and trust what comes out at the other end. And as you recall, it took us 20 years to develop that level of trust,” he concluded.

Once the engineering community moves en masse to the system level, that 20 years could easily be duplicated.

Low-Power Engineering discusses what’s missing from the ESL tool chain with Ghislain Kaiser, CEO of Docea Power.

By Ed Sperling
Models and higher levels of abstraction have been hailed as the best choice for developing SoCs at advanced process nodes, but at 28nm and beyond even that approach is showing signs of stress. The number of models needed for a complex SoC has been growing at each new process node, which makes it much more difficult to keep them updated and in sync as the design progresses down the flow.

There are architectural models, transaction-level models, IP models, software models, and more recently power models that span the entire design from hardware to software and even to manufacturing. Problems can creep in at every step of the flow, from the time they are created to the constant tweaks by design teams, which often are in different locations. Those tweaks are necessary for a variety of reasons ranging from optimizing performance to cutting or in some cases boosting power, as well as for adding or subtracting functions. But all those changes make it easy to skip a synchronizing step, which is critical in keeping a design on track. And it’s becoming even more critical as chipmakers move to design for variability and computational scaling on the manufacturing side.

“Being able to build models that talk to each other is a tools issue and a methodology issue,” said Shabtay Matalon, ESL marketing manager in Mentor Graphics’ Design Creation Division. “The problem is when you split into teams and not all the models are alike. That means the abstraction of the models above RTL are not the same.”

That’s particularly troublesome when the models are created by different groups or even different companies, which is the case with software and IP. The TLM 2.0 standard is a first step toward creating a standard that all other models can work through. The problem is that while there are hooks for the various power formats there are no tools to automatically create those power models. Large IDMs such as IBM, STMicroelectronics, Qualcomm, Broadcom and Intel are all developing their own power models at present.

“Because there is nothing available we’ve had to do it ourselves,” said Bhavna Agrawal, manager of circuit design automation at IBM. “It’s not because we love to do it.”

Power models are particularly troubling because they have to span all of the pieces, all of the functions, and all of the various power tricks and tools that engineers use to make complex chips. Turning on and off a single power island is a fairly simple thing. Turning on and off 20 power islands, and putting some into reduced states of functionality can produce unexpected results that requires constant adjustments, and each adjustment affects everything else in the design and all the other models.

More software and IP
The complexity increases yet again when software and third-party IP are thrown into the mix. Software developers have their own methods and models, but they’re not typically compatible with the hardware models. Having teams work side by side helps force the issue, and having project managers bridge both worlds also helps. But those ideas are just being tested by major chipmakers. In the mainstream chip world they’re almost non-existent.

“Right now we only model the hardware and load the real software,” said Frank Schirrmeister, director of product marketing for system-level solutions at Synopsys. “But we do have IP models, and keeping those models in sync with the rest of the design is a problem. Even being able to keep IP models in sync with the correct version of IP is not always trivial.”

It’s particularly troublesome because SoC makers increasingly are being called upon to develop not just the embedded software, but also to make sure the operating systems and application software functions correctly on a device. Cadence’s whole push into EDA360 revolves around starting from the software down instead of the hardware up. But that also means creating models from the top down that don’t exist today, and potentially integrating them with the models that do exist.

“One of the challenges is that you may make changes in the TLM that are not reflected back to the overall spec,” said Schirrmeister. “You need to make sure everything stays in sync, whether you update that manually or automate it by connecting the TLM with the implementation model. About half of the users of TLMs rely on software to verify the surrounding hardware, so that becomes the link between the TLM and the implementation world. But not everyone is using TLMs, either.”

Opportunity knocks
Many of the large IP providers, such as ARM, Denali (soon to be part of Cadence) and Virage Logic (soon to be part of Synopsys) are keenly aware of the need for sharing information among various models. But Mentor’s Matalon said that to effective, tools are needed to capture the user’s intent and translate it into models that are TLM 2.0-compatible.

“Most design today is based on re-use and integrating IP, which is why the leading IP vendors are moving in this direction,” he said. “But that also means the platform creators need to change. Some of them are invested in legacy models and that cannot be re-used downstream because the use of legacy models is limited to one task. You need to use the same model for verification and power and build models that are scalable and can be re-used at the back end of the process.”

In addition, design teams need to understand how all the models fit together. And at each new node, where complexity is making models much more attractive, they also need a way of updating the changes made in those models. And while that seems intuitive enough, it’s a lot harder than it sounds.

By Ed Sperling

Moore’s Law and low-power engineering are natural-born enemies, and this dissension is becoming more obvious at each new process node as the two forces are pushed closer together.

The basic problem is that shrinking transistors and line widths between wires opens up far more real estate on a chip, which encourages chip architects and marketing chiefs at chipmakers to take advantage of all that extra real estate. But more functionality layered onto a die also increases the demand for power—or makes the development of the chip much more complicated.

One way to deal with all of this is to drop the operating voltage across the chip. But decreasing the supply voltage has its problems.

“If you decrease the supply voltage too much, then circuits don’t work anymore,” said Mark Bohr, an Intel senior fellow and director of process architecture and integration. “There isn’t enough signal-to-noise ratio to make it work. But there’s also no silver bullet for this. One of our ongoing challenges is to scale transistors and operating voltage.”

How to do that is a rather difficult task, however, and engineers and scientists working on the most advanced chips on the planet say it will remain extremely challenging at all future nodes.

“There is a minimum voltage any ‘charge-based device’ can work on,” said Jan Rabaey, professor of electrical engineering and computer sciences at the University of California at Berkeley. “It equals 2 (kT/q) ln(n+1), where n is the subthreshold slope factor of the device. At room temperature and a normal device (n=1.4 – 1.6), this translates to approximately 50 mV. Given the fact that there is margin needed for reliable operation, a practical minimum voltage would be around 100 mV. There are some ways to lower this. High k is not one of them, as the main purpose of that is to reduce gate leakage. More effective is to reduce n (which is 1 for an ideal bipolar device).”

Power modeling, power islands
One solution is power modeling, which is almost required as more power islands are added to a system on chip. The advantage is clear—if the majority of functions on a device can be powered down or even off when they’re not in use—then the amount of power consumed by the chip can be dramatically reduced.

But complexity increases with the addition of power modeling. It’s harder to design, to route traffic and prioritize that traffic.

“Even at the architectural level people are reluctant to use multiple power domains in their design because they don’t want to complicate their system,” said Prasad Subramaniam, vice president of design technology at eSilicon.
”They don’t want to have multiple voltage regulators. A chip already requires two voltages, one for the I/O and one for the core. They don’t want to go beyond that.”

Verification adds another level complication. It’s much, much harder to verify the chip because that verification has to be done utilizing every state of every different function and in every different possible sequence.

“This is major problem,” said Srikanth Jadcherla, Synopsys’ group director for R&D for low-power verification. “But it isn’t a tools problem. The tools for verification are there. It’s a methodology and mindset shift. Engineers are not used to doing regression and debugging in this way. You have to change the whole thing under you.”

This is easier said than done. Tools can be swapped out, and even when there is more training involved that can be a relatively painless step. But changing a methodology is radically different.

“If there are six power domains and on/off nodes, then you have 64 possible combinations (more if there are more states than just on and off). You have to make sure the chip still functions in each state and that you can get out of one state and into the next,” said Jadcherla. “RTL engineers never bothered about system states before. Now they have to know the major states. A smart phone has a phone mode and an e-mail mode and a camera mode, so you now need to do mode-based testing. This is not something we see in the design community yet. Low-power verification must be done in the context of the system.”

New materials, methodologies and technologies—and challenges
At least some of the problems will be dealt with using new materials. While Intel added restrictive design methodologies at 45nm, IBM and AMD changed substrate material from bulk CMOS to partially depleted silicon on insulator (SOI). At 28nm and 22nm, IBM and its ecosystem—which includes AMD—are looking at restrictive design rules and Intel is exploring the possibility of adding fully depleted SOI.

Intel looked into partially depleted SOI technology about the time that IBM did and ruled it out because the cost was too high and the performance benefit based upon that cost was limited. But Bohr said the company is now looking into fully depleted SOI technology. There is no determination whether Intel will use that technology at future nodes, but it remains a possibility.

The difference between partially depleted and fully depleted is that in a fully depleted model the source and drain in a transistor are depleted down to the oxide. The channel is subsequently deeper, which in turn provides better insulation. With SOI, chipmakers typically can get a boost in either performance or power. But with performance now far less of an issue in most applications than power, the bulk, the focus is on SOI to save power.

“SOI technologies have a slope factor of approximately 1.2-1.3,” said Rabaey. “There is currently a lot of research on the development of devices with an ‘n’ smaller than 1 (such as Tunnel-FETs or TFETs, and other hetero-devices). This would allow for lower voltages. Right now this is purely experimental though.”

Conclusion
There is no simple answer to how power issues need to be addressed. The clear implication, however, is that design will become more complicated in some areas even as it becomes simpler in others. Restrictive design rules will limit what design engineers can do, but they will open up all sorts of possibilities for power modeling and engineering that never existed—or needed to exist before.

As IBM’s top engineers have said repeatedly, each new node requires some group to feel the pain. In the past, much of that pain was absorbed in the manufacturing and foundry process. The next phase will hit the design engineer and the verification methodology. After that, it’s anyone’s guess.

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.