By Ed Sperling
The move to future process nodes will require more than just new materials, better layouts and higher levels of abstraction. It also will require a fundamental re-thinking of how high-level architectural models are created and what’s included in them.

While the Transaction-Level Modeling (TLM) 2.0 standard has provided significant improvements for everything from layout to verification, power is creating a whole new layer of issues that is affecting everything from signal integrity to noise in the package and on the printed circuit board. At 45nm, many of those issues were manageable. At 22nm, with heavy IP re-use, multiple voltages and increased software-hardware co-development and verification, the existing models are falling far short of what’s needed for developing future SoCs.

“The most important thing to understand about power is that it’s global,” said Cary Chin, director of technical marketing for low-power solutions at Synopsys. “We’re used to working with hierarchical designs but power affects everything. If you look at logic, one corner of a chip doesn’t affect another corner. Timing is path oriented. Congestion is local. But when you think about power, if you dissipate one microamp it will affect everything else on the chip. All that matters is the total. And that goes for the package and the board.”

Surprise packages
For most chip architects, the package has been, at best, a nagging thought that has to be dealt with down the line. In fact, about the only real consideration has been the actual cost of the package, which can affect the overall profit equation for a new chip. That’s about to change in a big way.

Rather than just an afterthought, the package is becoming a big up-front consideration that can affect the overall functionality of a chip. That means it needs to be modeled more effectively, and it needs to be included in the initial architectural models. The cause of this change: power.

“On the package side over the last four or five years, the electrical properties of the package have not changed much,” said Dian Yang, senior vice president of product management at Apache Design Solutions. “But at advanced nodes the power of the chip is increasing. The original package impedance can handle 1 watt or even 10 watts, but now it’s 20 watts or more.”

There’s more to that equation, too. Impedance is increasing as the voltage is lowered to handle lower power, while frequencies are actually increasing from 100MHz into the gigahertz range. The result is more noise, which degrades signal integrity in a chip.

“You need to consider the package itself up front and how many layers you’ll need for power and signals,” Yang said. “Those decisions also have to be done at the very early stages of the chip, not later on.”

Package models also need to be beefed up to deal with these issues. Yang said the current power models are crude. They only deal with low frequencies and narrow bands rather than the broadband communication now required in all designs.
That leaves a lot of guesswork in the design of the package itself. Many companies overdesign, as a result, which increases margin—resulting in lower performance and higher cost—or they underdesign and cause problems in the functionality of the chip.

All a-board
The package is just a point in a problem that is escalating even further to the printed circuit board. For most chip architects, this is even less of a consideration, but power considerations have changed that considerably. What happens on the chip used to be largely separate from what happens on the PCB, but re-use of IP and parts is creating havoc almost everywhere.

“When we had a 3.3 volt part and voltage tolerance of noise at 5% voltage ripple, that was a lot of noise that could be dealt with,” said Steve McKinney, business development manager for Mentor Graphics’ Board Systems Division. “Today we have 1 volt parts and 5% tolerance, so the ripple tolerance needs to be tighter at the same time the current has gone up. The result is we’re seeing much greater demand on the PCB and the package to provide adequate coupling.”

Re-use of existing components and IP only exacerbate the situation. While it makes no sense to re-design everything on a 28nm SoC, which can include hundreds of millions of transistors, interfaces and complex logic, memory and I/O, not everything works perfectly the second or third time around.

“In the past, you had a whole plane running at 3.3 volts,” said McKinney. “Now you may have five different voltages with less copper, fewer channels for current and less opportunity for decoupling on the board. Everything on the PCB is being driven by the low-power requirements on the IC.”

Power trips
The problem with that scenario is that power isn’t being effectively modeled up front, either. Estimations are inaccurate at best, despite the need to account as early as possible in the design cycle.

“Power estimation has two components, characterization of the device and system activity,” said Pete Hardee, solutions marketing manager at Cadence. “With SystemC TLM models you’re abstracting data being simulated and at the transaction level you’re abstracting signals. But you have to bear in mind it’s an abstraction, and abstractions aren’t particularly accurate.”

That problem grows as IP is added into the equation. Qi Wang, senior architect at Cadence Design Systems, said that everyone agrees power needs to be estimated more accurately earlier in the cycle, but so far that isn’t possible. “The paradox is that you cannot get an accurate estimates of power. An IP power model is lacking, and with complex IP you cannot use a single number to model power. Plus, at the system level you have to deal with software. Power depends on the profile of activities. A different application requires different power.”

Conclusions
The need to plan for power in the architectural stage isn’t a new concept. What is new is an understanding of how many other pieces have to be built into that planning.

So far, there is no single model that can address all of these issues, from the IP, the packaging and the physical SoC, to the software that runs on it and the board across which all of this works. TLM 2.0 was a major step forward in raising the abstraction level of SoC architectures, which can help all the way through to the verification stage, but the next phase of development will need to incorporate more than just transactions.

This is complex stuff, for sure, and it only grows more complex at each node with re-use and as chips are stacked or connected with interposers. All complex designs begin with a good blueprint, but at future nodes that blueprint will need to be re-thought, revamped and expanded to include factors that didn’t need to be considered in earlier versions.

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
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: When do you verify closer to the metal and when do you move to a higher level of abstraction?
Pangrle: The higher level of abstraction is the wave of the future. It’s where things are headed.
Borgstrom: It’s been the wave of the future for the past 10 years, though.
Pangrle: But it is different the time. We’re seeing traction with customers and the blocks they’re using it with, and we’re hearing from them, ‘You know, we couldn’t have done it at this time if we didn’t have this tool.’ That’s different. There’s an efficiency that’s only going to ramp from here. But at the same time, we’re modeling in C. If the architects have the same hole with what they’re using and the same way they’re testing it, and that’s what you’re going to measure your RTL against, how are you going to catch a problem? The hole is in the model.
Narain: No, because when the verification engineer compares a mismatch between the RTL and a reference C model, then you can find errors in the reference model.
Pangrle: You can always find errors later in the process. People still check at the gate level and find errors in RTL.
Rizzatti: Exactly. Nvidia is still emulating at the gate level with hundreds of millions of gates.
Pangrle: Doing this higher-level stuff doesn’t preclude doing things at the gate level. But it does give you a higher level of confidence that if I’m taking C and using that to generate RTL, then hopefully I won’t have as many errors.

LPE: When do you know when you need to look at the higher level or at the RTL level?
Borgstrom: It’s really a continuum. Every project starts out as a concept, so you do some high-level modeling and algorithm development. Then it follows the classic ‘V diagram’ development where you go from that high level and make all the components. When you get down to that IP or block level, you’re doing very detailed verification, simulation and formal analysis. Then when you get all those blocks developed you start integrating them and do full chip verification involving simulation and hardware-software co-verification on a hardware-assisted verification platform. You eventually get up to full system integration where you’re prototyping with external interfaces. At each phase of the process you’re using a different set of tools to find a different set of bugs.
Narain: There’s top-level activity and then design starts in a distributed manner. Designers start implementing various pieces of a design based upon a spec, and then it comes together. So the design starts of as blocks, then it goes to clusters, and then to a full chip, and at every point you have a chance to use verification. The big questions are what is the cost, how much investment you’re going to make and what is the return. Typically block-level verification is compromised because there are too many testbenches to develop. People tend to do simulation more at the cluster and full-chip level. At every point in time you apply the cheapest technology. A lot of blocks can use formal verification. When you get to clusters, you need more sophisticated techniques. At full-chip level, you start getting into emulation.

LPE: Analog is separate, as well, right?
Narain: Yes, analog is different and you use your own techniques for that.
Borgstrom: There’s a dedicated tool chain for doing custom blocks and custom simulation. The designer and verification engineer are very often the same person. It’s a very close iterative loop. There’s a real need for doing mixed-signal verification once you start integrating the whole SoC with the analog blocks and making sure that analog-digital boundary is behaving correctly, both from a power perspective and a physical connectivity perspective.
Rizzatti: If you have a problem at the higher level of design in C and you don’t catch it, you don’t catch it at the RTL level?
Narain: That’s correct.
Pangrle: But the reference is the same.
Narain: No, what you’re saying is that you take the C reference model and automatically derive RTL from it. I’m talking about taking a C model and let the designers independently generate RTL. If you automatically derive RTL you won’t find the errors. If you use a spec and let the designers test against that, then it is conceivable that a bug will be caught.
Pangrle: There is a chance of an RTL to C mismatch. But it’s more likely that will be a problem with how the RTL was implemented. If I have some idea of what I’m looking for—and that’s usually defined by the architect—then I’m more comfortable knowing that what I’ve modeled has been turned directly into RTL. If I hand it over to an engineer to figure out my intent and then he goes off and does his own thing, then there’s even more likelihood of a mismatch. The mismatch will be more likely from the translation.
Narain: If you compromise on independence of fundamentals of the checking, then you’re compromising on the integrity of the verification.
Pangrle: This is like having multiple votes. You should have three independent design teams?
Narain: If you can afford it.
Borgstrom: It’s clear that this high-level design and verification flow is relatively new and controversial. But it does show a lot of promise.

LPE: Let’s swap topics. Software is becoming more complicated and so are power issues involving islands and various modes. What does that do to the verification process?
Rizzatti: It’s a nightmare.
Borgstrom: It’s a lot more complicated. The data we have shows that at about the 65nm node, average design team size is evenly split between hardware and software. As we get into smaller and smaller geometries we’re starting to see software-driven architectures where a lot of the value of the semiconductor product comes from software delivered along with it. When you have a huge software team waiting for software to come out, that’s not very economical. One thing chip companies are trying to do is figure out how to get their software teams started sooner. One way you do that is to come up with a virtual platform. You come up with a SystemC, TLM-level model of the overarching design even a year before you have silicon and get people writing software against that. As the RTL becomes more mature, you can put that into a hardware-assisted platform like an FPGA rapid prototype and continue your software development running at 10MHz to 30MHz prior to silicon commitment.
Pangrle: We’re seeing similar things in the market. There’s a shift toward software. Anything you can do to help teams get started earlier on software helps close that whole window down in terms of the amount of time they need to get a whole system up and running. We feel that standards help speed up this whole process. Using TLM 2.0 help is all part of the Open SystemC initiative. You also really want to know what the intent is of the design and how you’re going to partition it up, because that has an effect on how you start verifying it. Being able to determine which blocks you want to run at which voltage levels and which ones you’re going to use to create voltage islands—that’s information that gets passed down for verification. If I run everything at a single voltage, then I don’t have to worry about these kinds of issues. But if it makes economic sense to run a block at lower power, then I have all these other things I have to check.
Narain: Control over the design implementation process is a big problem. There is a strong requirement for software to eliminate errors in the implementation.
Rizzatti: The crossing point between hardware and software, according to Handel Jones, was 130nm. The other thing is that you start with virtual prototyping and after that you move to FPGA prototyping. If that were the flow, it would kill emulation. I don’t see that happening and that is not what the large chip makers are doing. There is a very clear moment in the flow where emulation is unique, which is the integration between hardware and software because the FPGA prototyping will not give you any ability to trace bugs. And we see this more and more.