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.