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

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

By Ed Sperling
It’s no secret that designing SoCs is getting tougher, but what’s surprising is just how far behind the existing EDA approaches are lagging.

The result is a growing gap between what’s needed and what’s available to do the job. In a presentation at the Tech Design Forum in Santa Clara, Calif., yesterday, Shabtay Matalon, Mentor’s ESL market development manager, said there is a 55% growth in the number of transistors per year compared with a 21% annual growth in productivity.

Much of this gap is in the consumer electronics space, where the demand for better performance and more functionality is coupled with longer battery life. Among design teams surveyed by Mentor, 61.8% are currently developing single-processor SoCs, while 20.8% are developing multiprocessing SoCs, and 5.2% are developing chips with multiple cores and multiprocessing.

Fast forward two years from now and the expectation is that only 30.1% of designs will use one processor; 20.6% will employ multiprocessing; 21.4% will use multicore technology and 19.4% will use multicore and multiprocessing technology.

“There is a gap between the power requirement and the power trend,” said Matalon. He said that if the power is allowed to trend upward at current rates it will far exceed the amount that’s permissible in designs.

“At the same time, you have to deal with software and verification and account for the power requirement,” he said. “There are two verification challenges that need to be solved. One involves design goal challenges where you meet functionality with speed, power and cost. Power is one of the biggest risks today because it’s evaluated at the end of the design. The second challenge is multicore and multiprocessing designs. If you wait until you get to the back end of the process it’s too late.”

All of the big three EDA vendors have been issuing similar warnings over the past year, saying that after 45nm it becomes increasingly difficult to build complex SoCs without electronic system level tools. While the exact node has been somewhat in flux—the numbers vary between 65nm and 45nm, sometimes even within the same chipmaker or EDA company—the message is essentially the same. And all agree that at 28nm and beyond understanding transaction-level modeling and automating some of the analog design and verification is no longer an option.

TSMC and GlobalFoundries have been working with all the major EDA companies on incorporating ESL models into their flows. Tom Quan, deputy director of design methodology and service marketing at TSMC, said that Reference Flow 12 is being developed that will incorporate 28nm, 22nm and 3D stacking. The new flow heavily leverages ESL tools, which are a critical part of design for manufacturing.

By Ed Sperling

Low-Power Design sat down with Walter Ng, senior director of platform alliances at Chartered Semiconductor; Brani Buric, executive vice president of sales and marketing at Virage Logic; John Sanguinetti, CTO at Forte Design Systems and Andrea Kroll vice president of marketing and business development at JEDA Technologies. What follows are excerpts of that discussion.

LPD: What will the differentiator be in the future?

Sanguinetti: We have to take as input designs that are relatively high level. Our customers tell us the higher the better. We spend most of our time in raising the level of abstraction. But we also have to be cognizant of what happens downstream. We don’t want to put out RTL that is junk. And it can’t just be acceptable to the tools. We want to put out RTL, for example, that can make dramatic improvements to power optimization. That’s true with any of the logic synthesis tools. But we don’t have very good visibility downstream, so we’re very reactive.

Ng: On our end, everything is about cost. Cost touches time to market and all the specs. We’re seeing much more widespread adopting of ESL tools. If you’re looking at power and selection of architectures, that can be most influenced at the system level. At the gate level, optimizing on power techniques, the wrong selection of an architecture can more than skew what kind of power you’re going to get. With more integration happening because of silicon’s capabilities, the more complex functions and the more important ESL should be. Getting from the algorithm level through system description, RTL and the physical implementation is a huge cost. The verification of each one of those representations is a huge cost. The more structured that approach can be, the better. Most of the leading edge of design is consumer applications, and these are extremely cost and power sensitive applications.

LPD: Why hasn’t ESL taken off until now?

Buric: It did. But there’s a difference between what has been used and what is commercially available. ESL has been adopted in one form or another over the last 15 years, at least. Most of those are internally developed tools targeted at a particular application. If you want to move from there to the commercial market, you have to make those tools very generic. That makes the problem more difficult to solve. But complexity of designs is going through the roof, so you have to start using these kinds of tools everywhere. If you’re not first-time right, you can lose your business or even your company, but you certainly will lose your market opportunity. It is now a must-have to make sure everything downstream matches your intent.

Kroll: One of the problems in ESL is the models are not of sufficient quality to estimate what’s going on in the technology later on. What is the power consumption, what is the area and what is the cost factor for the models. That’s the problem in the commercial market. You can’t make the tools broad enough and still use them for a specific task in an individual company for a specific application.

LPD: Does the number of models increase for each node?

Sanguinetti: That’s the way abstraction goes. We recognized we need a higher level of abstraction in ESL for the past 15 years, but it’s taken a long time to get to any kind of agreement about what it looks like. There are a number of approaches to it, which are largely overlapping. That’s what happened with SystemC. It took a long time before it became a standard. TLM is the same. There were a lot of ways of abstracting out interfaces. That’s why there are a lot of different models.

Kroll: They just specified TLM 2.0 last year.

Ng: As more folks come to adopt ESL and more is flushed out, this is part of a natural maturation of the process.

Buric: As this happens, you’re also going to see the rise of a second generation of ASIC vendors—eSilicon, Open-Silicon, Global Unichip. And due to design complexity, there will be an ESL signoff between design intent and design implementation if you don’t have a clear signoff.

LPD: Can ESL handle all the power islands that are cropping up in designs?

Kroll: I don’t think so. There are people already doing power analysis with SystemC and TLM 2.0. They are switching off components and making sure the dynamic power is captured properly. There needs to be more standardization on how to do it.

Sanguinetti: ESL can do anything. You can write lower-level code in your higher-level environment. It’s a bogus complain about ESL that you can’t do this or that. Maybe it’s as much effort to do it if you weren’t using ESL, but that doesn’t mean it can’t be done. In some cases, ESL hasn’t made your life easier—yet. But that’s where continuing work will be done.

LPD: Such as?

Sanguinetti: Power islands. Right now you put a module in one domain, another module in another domain, synthesize them and hook them up with an interface. Writing that abstract interface is work.

Buric: It becomes structural ESL. You have to partition the problem.

Sanguinetti: You want to be able to write code at a higher level, and what you take advantage of is the language’s expressability and the tools’ capability.

LPD: As we get to the next several nodes we’re facing restrictive design rules. Does that limit the demand for ESL?

Ng: Now that the flow is a connected flow, through RTL to physical, more and more people will be adopting it. They don’t have a choice. The challenge is creating a really good representation of the physical design at such an abstracted level. Even developing a synthesizer to put out good RTL good, dealing with the different interpreters and synthesis tools, is a challenge when it comes to power. Connecting that physical implementation is to the highly abstracted algorithmic world is difficult.

LPD: How do changes at the smaller geometries affect RTL?

Ng: From an RTL standpoint, not much. But it does affect the implementation of gates. We’re getting to the point where we will have to question what physical structures are allowed. We’re not saying they’re bad or good. But it will be a fairly limited set. From that to gate-level implementations that leverage those changes. I don’t know how you can comprehend that in a model. It’s more constraints on the physical implementation.