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.