By Ed Sperling
Power islands and multiple voltages used to be reserved for cell phone and process companies, but as more companies move to 65nm and 45nm process nodes these approaches to saving power—particularly in chips with multiple cores—are becoming mainstream.

The problem isn’t in the architecture of the chips, although that certainly brings its own set of challenges. More and more, the real holdup is at the verification level. While the percentage of time spent in verification has remained relatively steady—anywhere between 50% to 75% of the total time it takes between architectural design and tapeout—the size of the verification teams has doubled and in some cases tripled.

“Verification is the next big challenge,” said Naveed Sherwani, CEO of Open Silicon. “As an industry we have not done a good job managing verification. A new methodology would be very welcome. We have had to develop methodologies in-house to deal with this.”

Sizing up the problem
All of the major EDA vendors recognize the extent of the problem. They’ve been dealing with horror stories from the field since the 90nm process node. And according to TSMC, about two-thirds of the industry is now at that node or beyond.

The most advanced parts of the semiconductor industry are now working on 32nm and 28nm, with even more power states—on, off, sleep, and sometimes even more in-between states—more power islands and more processor cores. In the most advanced chips, some of those cores are even heterogeneous, which means they may have different voltages and states than the other cores. That allows a system to reduce power consumption overall and concentrate power where and when it’s most needed.

“When you cross 100nm, you’ve got to design this stuff in or you’re not competitive,” said Barry Pangrle, solutions architect for low-power design and verification at Mentor Graphics. “We’ve got a number of people well down the road on this. Larger companies with larger design teams can afford the engineering expense to make this work. But as more people go to more advanced nodes they’re going to be dealing with issues they never had to deal with before.”

The first thing that most designers encounter is complexity. What used to be done on a spreadsheet is much harder to manage now.

“There are a whole series of interrelated topics of increasing complexity,” said Srikanth Jadcherla, group director for R&T at Synopsys. “The state space is huge, and when you start dealing with three or four power islands it’s amazing how quickly the number of states and sequences explodes.”

It’s also amazing how complicated this stuff can get very quickly. Consider, for example, what happens when you’ve got a device and you’re checking e-mail. The processor wakes up a number of mixed signal blocks, then turns off what’s not being used. But that sequence also has to be ordered, which means you also have to order the power islands.

“You may wire it from low to high when you need to go from high to low,” said Jadcherla. “The problem is that you’re trying t predict island orders. You can create a safe graph, which is a set of possible states so you can look at a design and ask, ‘What are the safe ways this will work?’ But when you’re dealing with 36 to 40 islands, there’s no way you can set it up safely.”

Tales from the crypt
One of the most common mistakes that design teams make in chip engineering is internal organization and communication. The team design and communication has to reflect what’s going on in the chip design and verification.

“We’ve seen problems in a library group, for example, where they save power in a certain way that’s different from other groups,” said Mike Carroll, product marketing manager for front-end design at Cadence. “Communications between teams is not always the tightest loop. If one group instantiates it the wrong way, you may have power shutoff without state retention.”

In a library, that can be disastrous for a system—or at least some of the system’s functions.
It’s also a big problem in flash. Consider, for example, a smart phone where the low-battery signal is flashing and the system is ready to shut down to keep enough charge in the device to maintain essential data in memory.

“If you get a phone call at that time and you pick it up, it can be disastrous for the system,” said Synopsys’ Jadcherla. “But how do you prove that? It’s not easy. You need to come up with a methodology to test it. That’s where random constraints and testing come in.”

Another problem is when engineers route signals across other blocks or power domains. Pangrle noted that may not show up in the block diagram, particularly if the block is powered down.

“The key is to keep the logical hierarchy matching the physical hierarchy,” he said. “But design teams are not experienced with that. Another problem is that the signal may not be the same on one side as the other.”

That can also happen at advanced process nodes with process variations—an issue that no one even paid attention to at 130nm. At 45nm, it can be the difference between a functioning chip and a buggy one.

Advice from the experts
Low-power experts have consistently advised design teams to think about low power at the architectural level, and nothing has changed in that regard. What has changed are the numbers of possibilities for verification. Adam Sherer, product marketing manager at Cadence, said that for every power domain there are two-to-that-power possible states. So if there are two domains, there are four possible states, and so on.

“Verification does not have a theoretical limit, but pragmatically there are limitations,” Sherer said. “The problem is coverage. If you can manage to create a loop, you can extend it to the power domains. We’re seeing the same from the functional teams. Randomization testing is where the functional coverage comaes in. As long as there is coverage and you can see functional sequences you have vision into the power domain space. It has to be able to come out of shutdown and on the implementation side it has to work.”

That means establishing power intent so you shut off something at a particular time.

All the EDA companies say that a verification methodology helps, as well, although each favors their own flavor, whether it’s OVM or VMM. Other higher-level abstraction standards such as CPF and UPF, and TLM 2.0 also help significantly.

“With TLM you can figure out what’s in hardware and what’s in software and which blocks run at which voltage,” said Pangrle. “Then you can put in which blocks to shut down entirely and specify the power states.”

And if you can create an effective coverage model based upon those factors, then at least you have a chance of getting a chip out the door on time, possibly within budget, and one that actually works.

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: With multiple power islands and states, how do you ensure your coverage model is complete?
Borgstrom: The overall verification challenge explodes when you get into some of these low-power design styles. It’s not just coverage. It’s also catching the bugs in the first place. Our surveys show more than half the companies are using some sort of low-power design technique. Where we saw a couple of years ago it was one or two power islands, more common today is five or six. We’ve seen designs with up to 30 different islands. In the past, you could do ad hoc techniques. With even 5 or 6 power domains, you need some automation in there, whether it’s UPF-driven flows or multi-voltage simulation. This isn’t just for analog-like verification, either. It’s functional verification that the design actually works.
Pangrle: This is a trend that will continue, too. The amount of circuitry you can put on a chip is continuing to scale. People are using that to put on more processors and more cores. AMD came out with its first Opteron in 2003 and now they’re up to six cores. It doesn’t look like AMD and Intel are about to stop adding more cores. These chips are going into servers and often there are situations where some of these cores are idle. They’re all being measured by how much power they’re consuming in an idle mode. At that point, each one of those cores becomes a candidate for a power island so you can throttle it back or shut it down. The number of islands is just going to continue to scale. Having the process from the beginning, and looking at how you’re going to partition it with a format like UPF to track that information as it’s going through the design flow opens it up for the tools to look at what’s stored there and what the power intent is. That allows you to develop tests around it so you can make sure you’re verifying those different cases and different modes. But the reality is you won’t have all those states operating at the same time, so you can specify these are the allowed modes at one time.
Borgstrom: This also requires a shift in methodology and in how people go about verifying these low-power designs. What are the best practices in architecting a verification environment for low-power designs? You need to make sure you verify the power management unit and all the power transitions. One of the things we’ve done in collaboration with ARM and Renesas is write a book on low-power verification techniques called “VMM for Low Power.”
Rizzatti: The road map from Intel shows that by 2011 it will have 4 billion gates and 128 cores.

LPE: That’s the Larrabee chip, right?
Pangrle: Yes. And Nvidia has 512 cores. It’s 16 streaming processors, each with 32 cores.

LPE: But with low power, all of this has to be designed up front. Does verification need to be considered up front, as well?
Narain: Architects have to consider performance, timing and power.

LPE: But it’s also a business case that it has to come out the door on time, right? Do we need verification IP?
Borgstrom: More and more, verification is becoming a limiting factor on the scale and scope of the most complex designs. We’ve talked with customers that have scaled back the functionality of their designs and rejected changes in their design because of the impact that will have on verification schedules.

LPE: You mentioned VMM, and there’s been a lot of talk about how that stacks up against OVM. Does it matter which methodology verification engineers use?
Pangrle: Open standards matter. Mentor has donated technology for UCIS (Unified Coverage Interoperability Standard) and everyone has access to the UCDB (Unified Coverage Database) work that we have put together in terms of helping track information on coverage. Having that kind of format in the industry where you have the freedom to go from one vendor to another helps speed the adoption of these new technologies. If you’re using the tools from only one vendor then you’re at risk because if anything happens to that vendor you’re stuck. If you have a choice, you’ve got options down the road.
Borgstrom: The debate sometimes gets a bit tiresome. The industry seems to love a controversy. The VMM came out in 2005, so it’s been in production for five years. It has more than 500 successful tapeouts, lots of companies using it, and it has evolved and expanded since we first launched it. We’ve had quite a lot of interaction with our customers around methodology as we develop and enhance this. One thing we’ve heard is that customers want a single industry standard methodology that’s driven by an open standards body so they can have interoperable verification environments. When we first released VMM it was the first open methodology with a specification. We published details on the library and the methodology. We then open sourced the library and the applications built on top of it.
Pangrle: Sometimes you guys have nasty ties when you download your software, though. There are strings attached.
Borgstrom: It’s a standard Apache 2.0 license. There are no strings attached.
Pangrle: The .lib parsers supposedly are open, but there are statements in the access language about if there’s ever any dispute arising between the two companies then you immediately lose access.
Borgstrom: I thought we were talking about verification here. I’m not the right person to talk to about .lib. But VMM is available under Apache 2.0. In any event, there are two methodologies that have gotten attention. The cry I hear is from users who want one standard methodology and get on with innovating.
Pangrle: Does that mean Synopsys is going to support OVM?
Borgstrom: We support developing an open industry standard driven by an industry organization like Accellera. There has been great work done by the Accellera subcommittee. The next step will be to come up with a common base class library that will go a long way toward bringing unity and progress here.

LPE: What do the other participants think about this?
Narain: We’re neutral. We don’t have a stake here.
Rizzatti: We run a survey each year, and one of the questions is VMM vs. OVM. VMM is ahead of OVM in terms of checkmarks by visitors, but it’s not by much.

LPE: What’s the next big challenge for verification? Is it complexity, is it integration?
Narain: It’s the cost. And verification is such a multidimensional problem today that no one way is going to solve it. The only way to deal with this is to break it up into its pieces and to have the most cost-effective solution for each piece. One of the biggest problems today is simulation. We’re trying to throw everything into the simulation cauldron. We have to find a way around simulation. That’s where formal technology becomes important. But formal is an engine. If you don’t package it properly it’s useless.
Pangrle: It really is a cost-driven process in the end. People are trying to figure out how to get chips out the door with the least amount of expense and in the least amount of time. It really is more than just a point tool solution. Having tools that can go through and automatically look at the testbenches and vectors you’re running for your verification can improve the coverage with a fraction of the tests. Rather than just looking at how fast two simulators are, if you look at the whole system you can cut down the number of tools and get better quality results.
Rizzatti: Part of it is cost, but part of it is saving respins and not being late to market. If you’re two months late you can lose one-third of your revenue. That’s hundreds of millions of dollars.
Borgstrom: Two of the biggest drivers for verification are cost and software. They’re related, and they’re being driven by the complexity of devices today. What’s important is that there are different types of verification done at different phases. Whether it’s algorithm analysis or transaction-level modeling or RTL simulation or analog/mixed signal simulation or hardware-software validation on a virtual prototype—all of those have to work together in a flow. Being able to successfully transition from one phase to the next and making sure all the tools work together is really important.

Just how great is Synopsys CEO Aart de Geus? Well, considering the recent Kaufman Award build-up, which was about an hour of deification, you had to wonder who was paying for the meal. But now comes word from Harry the ASIC guy that everything you heard about Aart is true, and some things you never heard like his vision for analog IP (and the reason behind the MIPS analog group acquisition). 

As a point of reference, we’ll offer our own observation. For the past seven years, the only two major CEOs we’ve seen actually walking the DAC floor and talking to companies about what’s out there are Mentor Graphics’ Wally Rhines and Aart de Geus. That may say something about why the EDA industry is in the state it’s in right now. It may also say something about the two market leaders.

And then there’s that other nagging thought on the MIPS deal. The math looks good for Synopsys, but it’s not so good for MIPS. Check out Gabe Moretti’s blog on the subject, which cuts right to the heart of this investment. Incidentally, Portugal isn’t exactly know for its analog gurus, which is what made this acquisition so unusual in the first place. Gabe has a few other postings in the past week, as well, including what’s happening at DAC. 

While we get slammed for mentioning anything to do with VMM vs. OVM—we must be missing the point, of course—there is no shortage of development occurring in each camp. You’d think that if everything was one and the same that the two camps would perpetually issue joint releases. Amit Sharma’s blog about multi-stream scenario generation doesn’t seem to mention anything about OVM. For that matter, neither did Janick Bergeron‘s, who set the record straight on one-to-many transaction-level interfaces in VMM.

And speaking of religion, Synopsys’ Karen Bartleson has handed down the Sixth Commandment for effective standards, which is based upon a well-defined process. We have enough problems calling OVM vs. VMM a religious battle. Karen, you’re on your own.

–Ed Sperling