By Ed Sperling
Low-Power Engineering sat down to talk about IP with John Goodenough, vice president of design technology and automation at ARM; Simon Butler, CEO of Methodics; Navraj Nandra, senior director of marketing for DesignWare analog and mixed signal IP at Synopsys, and Neil Hand, product marketing group director at Cadence. What follows are excerpts of that discussion.

LPE: Where are the problems with IP?
Nandra: Customers are asking for IP blocks to be in the leading-edge technologies. You’ve got high-performance requirements for analog to reside in an SoC, which is designed for digital performance. Our customers are asking us to follow all the digital scaling trends without sacrificing performance. On the soft IP, there’s a lot more complexity in the functionality. There are requirements for PCI Express Gen 3 and USB 3.0. The complexity is increasing significantly. Plus, a lot of these things are standards-based but they want differentiated IP for power, area and performance.
Butler: The complexity of the systems is increasing. Assembling the IP and managing all the different interfaces and the various deliverables for the IP is becoming a real challenge. As these complex SoCs begin to integrate third-party IP, as well as the IP developed in-house, there’s no one person who has a full understanding of all the deliverables. You may have a person who understands the analog space but not the RTL requirements. There are a lot of derived views. One of our customers has 108 views for a single IP. When it comes to promoting that IP up to the SoC level they’re asking for automation around that and an integrated verification platform that can gauge whether a particular change fits with the consistency checks across the views.
Hand: One of the big changes is the scope of what is expected to be covered in a piece of IP. As the amount of IP being used and the complexity increases, so does the scope of a particular piece of IP, both in terms of how much functionality it covers and the verification environments. A big part of that as you get more IP you have to move up a level so each piece is more manageable. Otherwise the integration of the SoC becomes an intractable problem.
Goodenough: The main change we’re seeing is that IP is expected to operate on the bleeding edge of physics and software. We see a twin challenge to make sure the IP is validated, packaged and fit for purpose in those two domains. We’re doing that in an environment that now has pace—the level of pace that’s required in engineering with the IP consumers is the key differentiator. You’re concurrently developing the IP with your lead customers, who are on the edge of physics and on the edge of software. IP is becoming less of a nice little box and more of a concurrent engineering process. We see this trend that a lot of activity in IP re-use assumes a stable world, and the world is not stable. Things like change management—managing ECOs, configuration management, managing patch levels—that’s where all our focus is. We can define what RTL is. We can define what a piece of verification IP is. But there is never a stable definition because everything is evolving.

LPE: What you’re talking about is context. The context is more complex, right?
Hand: That’s correct. You may want to explore the PCB environment it’s in and do a signal integrity analysis to make sure it all works. Other customers want it all to fit into a virtual system model to combine with the rest of their IP. Everything is becoming much more concurrent. The good news is it’s driving a lot more of the EDA tools and technologies that have been out there for a while.
Nandra: When your customers are challenged with really short product cycles, they want the IP quickly—even when the technology is not stable. We’ve started designing 28nm and 20nm IP with very early versions of the PDKs. It’s a mini-context. You have to design in an environment where the stuff around your IP isn’t stable. When it gets into an SoC that’s another context, where you have to figure out noise and coupling and SKU. And there’s a context above that, at the system level, where people have to figure out how the package and the lead frame relate to the IP and how that relates to the SoC. It’s almost like multi-context. But IP is at the lowest end of the food chain. If there’s a problem, you get the phone call first. A lot of time we find problems in the cable or the connector or the board, but we’re the ones who have to figure it out. The upside is we learn a lot about cables and connectors and boards, which is critical to our IP business.
Hand: If you look who’s buying IP today, a lot of times it’s customers who never bought IP in the past. Now you’ve got standard interfaces that don’t add value for the customer to build themselves. What’s changed is that in the past the IP market was one step behind. Now it’s at the leading edge.

LPE: But not everything is always on and off. Sometimes it’s somewhere in between.
How does that affect context?
Goodenough: One aspect of IP quality is whether it is functionally fit for purpose. The scope of environments you’re trying to validate for scales up. If you take BIG.little, you’re validating a multicore system that’s interacting in complex ways with BIG.little switches, hypervisors and operating systems on top of that. As an IP provider, you’re now anticipating the environment your IP will be deployed into. Otherwise, everyone will be pointing back to the IP provider if there’s a problem. If you don’t understand the context—complex software and physics environments—you don’t know whether it really is your problem. ARM works in partnership from the applications developers down to the foundry. A key part of IP is being able to understand the context and marshal the ecosystem, not just today but to what it’s going to be next year. With a big multicore system running the latest version of Android in someone’s SoC and it’s just fallen over, who’s problem is it? We’re putting a lot of emphasis on system debug and system finger-pointing. One of the biggest challenges on schedules is trying to triage the debug and find out where the problem is. It may be an SI problem on the board. It could be in the driver.
Hand: That’s what’s driving a lot of it. If a customer outsources a piece of IP, they’re also outsourcing their core expertise in that area. Who are they going to lean on for their expertise? It will be the IP provider. The IP provider does have to understand the whole concept. You do have to become the expert.
Butler: Yes, you become the fall guy.
Hand: You are the expert and you quickly have to get to the cause of it. If it’s your problem the customer knows you will fix it quickly. If it’s not, the customer knows you’ll determine it’s in a specific area.
Butler: So how do you monetize that kind of expertise?
Hand: It depends on the context of what’s going on. With leading-edge IP, there’s a larger business agreement because you are assisting them with that. But it was no different when verification IP started. When something died, the first assumption was the verification IP was bad. This isn’t different.

LPE: Is IP really being characterized properly?
Butler: No. One of the problems we see when we look at the design methodologies inside big SoC houses is they’re looking for a continuous build approach to hardware design because they have so many software and firmware variants they’re using to make their offering unique. What they’re finding is just doing the validation is a huge problem.
Goodenough: We internally and externally see this as a configuration management problem. At one time when you looked at configuration in an SoC it was all about how to rapidly do X, Y or Z. Now the hardware is pretty much fixed. You’ve turned this piece off, you’ve tied this one off, and now it’s a different software stack in the mobile space.
Butler: And there is so much complexity in all these different levels that people are scared to release blocks because they worry they’re the ones who are going to break it. They don’t have visibility across all the various pieces. The tools are still catching up, particularly when it comes to hardware-software compatibility. It’s kind of a black art.
Nandra: Each customer has a different constraint file set up. You have to shift those unique constraints to that customer. An interesting statistic is that it can take up to a month to download a library. Those databases are getting huge.
Goodenough: The file sizes are terabytes.
Nandra: The corner sets are becoming unique. You have constraints and corner sets and all these environments they’re looking at.

LPE: What’s the solution? Is it to provide more context or more pieces, such as subsystems?
Hand: It’s a combination of both. One part is the pieces will get bigger as a natural evolution. The other is giving people tools to explore the context, whether it’s hardware or software or co-verification. A third part is a way of capturing the metadata that defines that IP within a different context. That way you have a way of exploring the architecture with the metadata that defines this level.
Butler: The barriers are getting blurred and the IP provider is becoming an extension of the design team. It’s starting to sound like an outsourced design environment.
Nandra: The customer is expecting you to be part of the design team until the product gets out the door.

By Ann Steffora Mutschler
Assertions. Just the term conjures images of writing boring lines of code to feed into a simulator. But for engineering teams working at the 40nm node, the pain of making sure their verification is complete and accurate is real—and so is the potential for literally melting silicon if something goes wrong. With this in mind, ‘boring’ goes out the window and gets replaced with ‘necessary.’

Assertions have a long history in verification, noted Krishna Balachandran, director of low power verification marketing for Synopsys. “They emerged and became popular about 10 years ago because there was a need to improve the verification productivity. You had tools dealing with the back-end flow that were constantly beating on performance, which is the same with simulation. We try to improve the performance to simulate things faster. In verification, there’s a design/verification gap. Designs are growing faster than verification tools and technologies are able to keep up without putting the undue burden on the number of engineers required for verification or the number of computers required to verify a design. Assertions were a way to boost that verification productivity.”

The driving force behind assertion usage is accuracy. Increasingly the engineering teams that are building power awareness into their designs want to know how to build this into their environment. But they also want to be sure, given the NRE costs and all the rest, that its going to work, observed Adam Sherer, product management director for Cadence’s Incisive simulator tool and secretary of Accellera’s UVM committee. “At 40nm and below, the chips are just going to melt. The industry can’t afford to do anything else. The chips will not close without this—40nm is about the transition point where this really becomes acute.”

Assertions are used primarily to validate the behavior of a design and are also used to provide functional coverage information for a design. They can be checked dynamically by simulation, or statically by a separate property checker tool such as a formal verification tool that proves whether or not a design meets its specification. But there is also some confusion about what exactly a low-power assertion really is.

“The term ‘low-power assertions’ probably can mean different things to different people. From my perspective…an assertion is a particular kind of way of making a statement about something—in particular, a statement about behavior of a design—such that certain values will appear on certain signals at certain times,” said Erich Marschner, product manager for Questa Power Aware Verification at Mentor Graphics. “Typically you use it to define sequences of conditions over time. It is also used more generally to mean checks that are made as part of the verification process. While not all checks are functional, some of them are structural or apply at different levels of abstraction.”

For example, when a design is divided into power domains, those domains must be able to interact correctly. That involves looking at the power states of the system, which domains can be in what power states at what time, and whether there is any isolation or level shifting required because of two domains that are interconnected but in different power states at the same time, he said.

Cadence’s Sherer noted that the bulk of projects today still aren’t using advanced power techniques. “For the companies that are using any of the power aware structures—frequency modification, voltage levels, power shut-off, or any of those techniques that are very focused—all of those have very specific triggering activities. They have specific signals that set up the condition by which the power is going to change and to set a recovery from that power condition. That’s when assertions start to come in because there are two aspects that our users are very concerned about. One is, for a given power domain, is that being affected correctly? Did I set it up correctly? Do I recover correctly? What are the input and output signals? Are those being properly sequenced? And that is a key thing—that it’s properly sequenced.”

For an engineering team that may have just one power domain, their first power shut off can probably manage by hand, he said. “The assertion is good, but you can look at the waveform tool and you can probably figure it out. But if you have three or four power domains and they are overlapping and some of the signal triggering is coming from software, some of it’s coming from hardware (obviously they are all manifest in hardware), now you have an interesting dynamic that may go beyond casual observance in a waveform tool or human proof point.”

Power-aware simulation tools contain a collection of these checks, with a large number of the static checks done by analyzing the structure of the power intent that’s described in the CPF/UPF and comparing it to the power states that are defined in CPF/UPF. The power states report what states various domains will be in, the structure of the design dictates which domains are connected to which other domains and other parts of the UPF specify whether isolation or level shifting should be inserted in certain places.

By comparing all of this and analyzing that information, the engineering team can tell whether the isolation and level shifting has been inserted in all the right places for all the possible power states that have been defined in UPF/CPF, Marschner explained.

“To verify an assertion you really have to have full functional information about the design. One of the interesting problems with low power is that, depending upon the level of integration, you many not have all the information necessary to do the verification—or at least the static analysis of all the possible behaviors, which is usually how assertions are used in a formal context. This is especially true if the low power activity is driven by software ultimately,” he added.

What’s Next?
To leverage the full strength of assertions and their role in a low-power/power-aware design methodology to improve the accuracy of verification—particularly below 40nm where things get really painful—the industry must bring some pieces of today’s verification technologies rather than continuing to look at verification as a standalone process.

In-situ verification with power intent could be a way to go in the future in terms of bringing different technologies together, suggested Vic Kulkarni, general manager and senior vice president of the RTL business group at Apache Design.

In the case of Apache’s RPM technology, he explained that it was disparate groups within the front end and the back end that did not talk to each other creating power budgeting issues. “By bringing a technology that fuses these two worlds together, it brought the front end to influence the back end power delivery network and power integrity and so on, which essentially helped the designers trying to optimize their power grid, for example, instead of over-design or under-design. Similarly, one can think of a scenario in the verification world where people who are doing day-in, day-out verification, the classic verification companies or business units, have to start crossing the boundaries and bringing the UPF and CPF world and the designers intent world together to create the next generation of low power design methodology.”

In the meantime, noted William Ruby, senior director of RTL power product engineering at Apache Design, customers are putting together power regression methodologies. “You used to have functional regressions. Even the power intent CPF/UPF-driven is still kind of functional in nature. But power regressions are all about power consumption. The idea here is that you want to track your power consumption early on in the design cycle before synthesis, especially as you freeze the RTL and then you start fixing functional bugs. Going through the functional verification process by fixing a functional bug, you may introduce a power bug and if you don’t catch it. The power bugs we see are not going to magically fix themselves in synthesis or place and route. At the end of the day you’re going to get a nasty surprise and that’s not something you want to see.”

Whether the vectors are being generated automatically, pseudo-randomly or special testbenches, engineering teams are throwing everything they’ve got at power consumption verification. And for now, that’s about all they can do.

Low-Power Engineering talks about challenges in IP with Neil Hand of Cadence, Navraj Nandra of Synopsys and Simon Butler of Methodics.

By Ed Sperling
There are many ways to measure power and heat in an IC, and each one of them adds tremendous value to a design. But there are still holes, and those holes are just beginning to get filled.

Power and heat have emerged as two of the most persistent problems in advanced designs, and there is no single or simple way to tackle either of them. Nevertheless, there is at least progress on this front.

“Power is a side of complexity that has many, many dimensions,” said Aart de Geus, chairman and CEO of Synopsys. “We have multiple power domains and we now have states between on and off. How do you deal with that with ones and zeros?”

At the highest level, high-level synthesis can be used to provide generalizations about whether one processor versus another, or one piece of IP versus another will save power. The challenge there is to link those HLS models with other models to make them useful. This has been an ongoing challenge for startups such as Calypto and Forte Design Systems, as well as Synopsys and Cadence. (Mentor Graphics spun off its Catapult C platform to Calypto last year.)

At the lowest level, starting with RTL and even down to the gate, measurements are extremely accurate and useful. The problem is that once RTL code is written, it’s more difficult to change. Providing that kind of information early, and in context, has been a major challenge. Apache Design has created an RTL Power model, for example, as well as an RTL power flow and a chip-package-system model and flow to extract that information early enough to include it in the RTL.

The big missing piece, however, has been even earlier in the design process. What happens, for example, if a processor from one vendor is substituted for a processor from another vendor? Or what if signal traffic is routed one way in a design versus another? These are important tradeoffs at the architectural level, and there has been only scattered progress in this area. That’s partly because most of the complex thermal and power modeling for advanced is still being done with spreadsheets rather than with automation tools.

Docea Power jumped into the market this week with what should be an interesting first step. Its new AceThermalModeler software is aimed at architectural-level exploration and analysis for heat and power. The focus is on early system floorplanning or partitioning, system packaging, integration architectures and power management policies. It’s a certainty there will be other entrants into this space of the next year or two. All of the major EDA companies and their customers have been talking about the need for this kind of technology since designs reached 40nm.

But Docea CEO Ghislain Kaiser said the spreadsheets literally have run out of room at advanced nodes. They cannot handle any more data. What’s needed now is a way of raising the level of abstraction with accuracy, and he says there is an opportunity between the complex algorithmic approaches used for signoff and the packaging data sheets that are too far from reality. It remains to be seen just how quickly this market will ramp up as a result of that, because the next challenge will be to integrate this kind of information—all of it, from the high level to the pathfinding architectural models—into existing flows. That includes companies designing chips, as well as the ESL flows that are created by the Big Three EDA vendors, and the modeling standards groups such as OSCI, which developed TLM 2.0.

All of this will take time, of course. Standards groups move cautiously and large companies don’t make rapid changes to flows that work. Still, the need for more analysis that can be integrated throughout the design process is clearly needed.

By Ed Sperling
Low-Power Engineering sat down to discuss the problems of identifying and verifying power issues with Barry Pangrle, solutions architect for low-power design at Mentor Graphics; Krishna Balachandran, director of low-power verification marketing at Synopsys; Kalar Rajendiran, senior director of marketing at eSilicon; Will Ruby, senior director of technical sales and support at Apache Design; and Lauro Rizzatti, general manager of EVE-USA. What follows are excerpts of that conversation.

LPE: What standards do we need that we don’t have?
Ruby: My vote would be for a power-consumption level. That’s absolutely critical. Gates have their own built-in standard cell libraries and power models. You abstract to RTL, and we have found a way of using the same standard-cell library. But once you go above RTL there is nothing in terms of power consumption models.
Pangrle: With UPF, SAIF (Switching Activity Interchange Format) had been included. The standard is really set up for power intent. But when you look at the back, there’s this ‘SAIF’ information, as well. There has been a little bit of talk on that committee about what we should be doing with this. If you’re going to have any type of standard to specify the energy coming out of a given part, that’s going to be tied to some activity. You have to have some way of specifying that, as well. There is a potential for tying that together in the future, whether it’s there or somewhere else.
Rajendiran: By definition, a standard means multiple parties need to talk. Models have come out of that with standards like UPF. You can specify the power intent, but that’s a very high level. Where it gets implemented, when you’re splitting microwatts and nanowatts, it’s necessary but not sufficient. You need a standard, but you need good tools and someone who can combine the high-level intent with all the nitty gritty low-level details of the variants and power and know how these things will be put together and verified. I don’t think we’ll ever have a situation where you push a button and determine whether function is correct and timing is correct and power is correct. If we do, that means we have stagnated. We will always have something pushing us.

LPE: But we’re still at the point where we don’t even know how to write testbenches for power, right?
Balachandran: Yes. When a customer starts with their first low-power design, they’re struggling to figure out what to do to exercise all the low-power functionality in the design. If the customer is more experienced, they already have a way to do that. They’re learning how to do a low-power design from a test perspective. Creating that first test plan and testbench for a low-power design is not a trivial task. It’s a huge methodology change. They’ve got to invest resources in terms of learning what it takes to do it and allocating resources to do it. That challenge is still not solved.
Ruby: If you look at it from a hardware perspective you’re absolutely right. But if we can somehow leverage the applications running on this hardware and transform them to testbenches, that would be another element of this solution.
Rizzatti: But is it the embedded software doing that? The application is the embedded software. You don’t have to invent anything.
Pangrle: It’s been a challenging transition for the hardware guys to deal with all the complexity brought about by power. If you look at the software, it’s almost always been purely about functionality. Either the software works or it doesn’t. Now you’re asking the software guys to look at the way they write their code because it can have a big impact on the performance of a device.
Rajendiran: A developer writes a piece of code and even provides a way to test it. The developer knows the guts of the software, so he comes up with a test plan. We used to call that white-box testing. Then we also used to pick up the most junior guy and tell him to do a black-box test. The reason we did that is the developer knows a certain path to exercise. If you give it to some random guy he’ll exercise it in ways the developer never thought about. It’s probably impossible for the developer to write a test plan for power, though. You probably need a combination of test plans. The better companies have people writing power verification plans and the developer writes the functionality part.
Balachandran: I’ve seen the same thing. The designer and the verification engineer are still working independently. The design engineer is not the verification expert and isn’t the architect of the low-power system. The verification engineer comes from a software background and has expertise in writing a test environment without much of the low-power hardware knowledge. The low-power architect has very little idea about how to write the software and how to write the testbenches to test his design. It’s almost as if you need a third person who knows enough about both of them to be an intermediary in order to close the gap. That’s the challenge companies are facing. You either have a verification expert, who is not a low-power expert, or you have a low-power design expert who doesn’t have enough knowledge of the verification concepts. Large companies are investing a lot in methodology. They have low-power methodology teams in place, and they’re tasked with coming up with the proper flow to get this working. Some companies are expending as many as one or two years to come up with the right methodology for their environment before they put a flow in place for their design teams.
Ruby: What if you can say, ‘Look, I’m designing this chip for a cell phone and I can verify it runs this operating system and 500 applications?’ If I forget about testbenches and power and I can just run the applications on my hardware, to me that would be golden. So can you run an application to analyze your power grid? That’s a big question.
Balachandran: That’s a great idea, but the apps don’t come out before the product is launched in many cases. How do you test for that before you get the product out in silicon and ship it? That’s where the challenge is.
Ruby: You test it the same way as our customers do. You test it with what you’ve got at the time.
Balachandran: That requires a very big effort on the part of the software developers for an application and the system providers working ahead well in advance. Only a couple companies in the world have that kind of clout.
Ruby: Look at the consolidation in the semiconductor industry. That’s exactly where we’re going.
Balachandran: But even those companies that are the system builders are sourcing their ICs from different companies. This has to go down the chain where the IC companies have those requirements and specs for apps in mind from the beginning, because if you talk to the typical IC maker they don’t care about apps as much.
Ruby: They should.
Balachandran: Maybe they should, but it’s a big change in the entire ecosystem. It’s possible, but not easy to accomplish.

LPE: What happens with stacked die? Does that change the verification process because there are new issues with power in stacks?
Pangrle: That’s more on the physical side. On the functional side it’s just a bigger system. On the physical side, the interaction of heat dissipation comes into play. If you’ve got a single die you can stick a heat sink on top or do some active cooling. If you start stacking something in the middle it doesn’t have a direct path out to that heat spreader anymore.
Rajendiran: When you think about flip chip, it took 30 years before it came into common use. The reason is that we have vectors pulling us in different directions. On one hand the mobile and consumer space are pushing us into the cheapest and lowest power. That’s a completely different direction than some of the biggest companies are taking. The biggest benefit people are looking to gain with stacked die isn’t low power. It’s that the cost is too high to move to 28nm or 22nm. Already verified chips at 180nm are perfectly fine because that portion doesn’t need to run that fast. If you combine 180 and 130 and 65, and maybe do the logic that ties them together in 90nm, time to market is the key.

LPE: But when you verify that, three good chips don’t necessarily make one good stacked die, right?
Rajendiran: No, and verification will continue to be a challenge. We need standards and models, and the verification will only be as good as the model. The overall full-chip model has to make some assumptions about timing and power, and that has to come from the IP supplier and manufacturers.

Low-Power Engineering sat down to discuss the problems of identifying and verifying power issues with Barry Pangrle, solutions architect for low-power design at Mentor Graphics; Krishna Balachandran, director of low-power verification marketing at Synopsys; Kalar Rajendiran, senior director of marketing at eSilicon; Will Ruby, senior director of technical sales and support at Apache Design; and Lauro Rizzatti, general manager of EVE-USA. What follows are excerpts of that conversation.

LPE: How does IP affect verification from a power perspective?
Pangrle: In the old days you’d see processor cores quoting watts per megahertz. When you’re operating at a standard clock frequency and voltage the whole time there is no other state that’s at least a reasonable approximation. Now you look at the levels of complexity going on above that with multicore designs that may be operating at different voltage levels or different clock frequencies. Watts per megahertz goes right out the window. There is a challenge in how you get that kind of information. If I’m a designer working in an SoC I’m trying to figure out what is my lowest energy core to put in there and what voltage and what frequency you want to run. How do you make these tradeoffs if you don’t have any data to work with? And then, once you have this, how do you hook it all together. You need to give that to the customer who’s going to use all this IP. That can be a third-party IP from outside or IP that’s developed in-house that you want to re-use from project to project. How do you keep that information so the next designer who picks that up knows how to use it? That’s complicated further by the fact that a lot of control for these SoCs is moving out of hardware and into software. From a verification standpoint you need some environment where you can bring in the software and get an idea. Often what’s going to determine the power is the software running on top of it. With phones we see instances with software where you download an update and your battery life gets a lot better—or it gets worse.

LPE: We’re used to verifying pieces of this, but now we’re dealing with interactions, as well. Don’t we have to raise up the level of verification?
Pangrle: You do. There’s almost a renewed interest in the high-speed emulation. Clock frequencies, especially for x86 processors that are used for most simulation, have stalled out since about 2004. We’re getting access to more cores, and if you’re doing regression tests that’s good. But if you’ve got software that you need to run and you can’t break that up, then the reality is that single-threaded performance hasn’t increased much. We’re seeing a lot of interest in higher-speed simulation and verification to help address that problem.
Rizzatti: Raising the level of abstraction won’t do any good in computing power consumption and verifying power domains because you don’t have the accuracy. Here we are really talking about cycle accuracy. Emulation is the alternative. It’s cycle accurate but you have performance that is orders of magnitude faster than a simulator. You can simulate the interaction of the software with the hardware and verify power domains turning on and off. There is lots of interest here.
Rajendiran: With chips becoming more complex and larger, if you have 100 power islands, at any time you may have one or two operating and the rest you want to put into a lower power state. So how do you know those things have been turned down to a low power state? That becomes a verification challenge. The more domains and islands you have, the bigger the challenge to make sure your intent is implemented at the chip level.
Ruby: Power verification has many different aspects. There is power intent verification. There is power consumption verification. There’s probably also something to be said about power integrity verification. Test power is orders of magnitude higher than functional power because all of the low-power techniques and clock gating are not working in the test mode. Everything is open and running at the same time. You have to verify physical power integrity, as well. Verification in the past used to be RTL or something above that. For power it needs to be done at multiple levels, from the system level to RTL. And what do you feel comfortable with? If you do RTL emulation you can understand the hardware behavior of your design. The question is how does software drive that hardware. Can you establish that kind of behavior in accelerators, or do you need to bring the hardware up a level and truly make it work with the software? Based on the RTL description we can estimate power consumption. The further you move up in levels of abstraction the more you lose. At the gate level you get good accuracy. As you move up to the RTL you start losing accuracy. As you move up to system level you may lose so much accuracy that the analogy becomes useless. There is a tradeoff here between the types of verification you do at the higher level, including power consumption, and the turnaround time that’s required.

LPE: Aren’t we changing verification, though? We’re taking it both up in abstraction and down to the most basic level.
Pangrle: It isn’t an either/or issue. It’s an ‘and.’ You need to be checking this at multiple levels. You can’t ignore one level and hope everything will work out okay. You have to make sure you’re accounting for all the different scenarios a complex SoC may run under. One thing that gets challenging is that if you’re looking at running software on a virtual prototype or some type of accelerated environment, you can’t run that many cycles when you’re looking at what’s happening on the power grid. Only certain pieces are of interest to you. When it’s doing what it’s supposed to be doing most of the time, that’s probably not where it’s going to fail.
Balachandran: Software verification is important. A lot of it is also done with methodology. The verification methodology is changing compared to non-low-power verification. They also have a link to SystemC simulation in their environments. And we are seeing customers with a renewed vigor to do gate-level simulations. Some customers now have a methodology of not taping out their chip without doing more extensive gate-level simulations for the power. The low power has caused a renewed focus in that area.
Rajendiran: When you are splitting microwatts and nanowatts, you have to go to that level. RTL was great 20 years ago because you were doing simple blocks with 20,000 gates. There are so many libraries at the same process node and for the same flavor that it really becomes very critical which library you pick. That can have a huge swing factor for a mobile device. If you have a chip verified in this process at this foundry but it’s not at a price point you like, you can’t just move it. Gate-level is becoming a lot more important at that perspective.
Rizzatti: A simulator running at the gate level will take forever. We’re talking many years.
Ruby: We need to do this with multiple levels. But one of the key elements of the solution involves technology-dependent models that can take you through the levels of abstraction. There may be multiple models for multiple levels, but you may want to say you’ve done this design and you know what the power profile is and you can measure all the way down to gate or transistor level. You can then abstract the model for that block, push it up several levels of abstraction, and still maintain as much accuracy as is practically possible. You can do this because it’s not being done from scratch. If you don’t a netlist and you don’t have a post-synthesis result, you can still estimate power consumption based on RTL and create an RTL power model. Technology-dependent modeling, not milliwatts per megahertz, will be the key to this puzzle.

To optimally address all the requirements for each application, there is a new generation of advanced data converter IP that includes Nyquist rate high-performance, high-speed ADC products, based on a highly optimized pipeline architecture. This paper describes the main power versus resolution trade-offs existing in the design of pipeline ADCs. It also discusses how digital gain calibration – one of the key techniques employed – eases those trade-offs, thus achieving significant improvements in power and area.

To download this white paper, click here.

Low-Power Engineering sat down to discuss the problems of identifying and verifying power issues with Barry Pangrle, solutions architect for low-power design at Mentor Graphics; Krishna Balachandran, director of low-power verification marketing at Synopsys; Kalar Rajendiran, senior director of marketing at eSilicon; Will Ruby, senior director of technical sales and support at Apache Design; and Lauro Rizzatti, general manager of EVE-USA. What follows are excerpts of that conversation.

LPE: What’s the big challenge with verifying power in an SoC?
Ruby: Power has a couple of different components. One is how the low-power techniques impact functionality. If you talk about things like power gating, power supply shutoff, multiple supply voltages and so on, this is where you need to understand certain rules of turning on and off power supplies. You need to be able to create retention cells, to be able to retain state, and to retain functionality. That’s one major aspect. The other side is that you have to look at the power consumption itself. How do you verify that you are on target, if you have a target, and that you are not exceeding a specification? And how do you ensure the design has efficiency built in.
Rajendiran: This is all about is trying to verify what your intentions were that you stated in the beginning and making sure that has been implemented—and when the chip comes out, making sure it is functioning that way. In the old days we simply meant functional and timing verification. Now, just on the functional side, it has become so complex that just getting it out the door is a challenge. It’s the same with software. No one thinks about verifying it all. That’s the practical problem. The person who is verifying the power states doesn’t have the time to put in the right hooks. We have the Unified Power Format to help, but we still don’t have standardization as to how you verify the states. Tools rely a lot of naming conventions, but even though there are fewer companies there is still not compatibility in reading all of those things. Tools are always playing catch-up, too. The ideal solution will be a combination of great tools and planning. In addition, you can have the best tools, but if you put them in the wrong hands you don’t get results.
Pangrle: There’s a functional part and a physical part of verification. A lot of what is going on in the industry right now, especially with the power formats and the convergence around UPF and the 1801 IEEE working group, has been to keep the power intent separate from what has been the standard part of functional verification. It’s allowing people to use their standard flow, take it to RTL, and still be able to design RTL blocks that can be used in different design scenarios with different power management. You don’t have to hard-code isolation, level-shifting, retention registers into those blocks. You can still design your block your same way, and if in one design you’re going to power down that block that’s okay because the intent information is in a separate format and you can bring that in. From that standpoint, there has been good collaboration between EDA companies and their customers. From the standpoint of putting it all together and being able to support the tools, one of the things we’re seeing is that as EDA companies work with designers there are times where something is a little different and different vendors have created support. That’s where it gets tougher to move designs from one company’s set of tools to another. It also brings up some new questions. From the physical side, if you’re powering up and down blocks it has a real impact on your power grid and whether it’s going to function. Just because logically it looks as if it should work, that doesn’t mean when you get your chip back from the foundry you’re not going to run into other issues. And in terms of the complexity of testing, you can do the standard ATPG, but when you go through the dynamics of running different voltages and frequencies and bringing things up and taking them down, to what extent are you actually going to test that?
Balachandran: Verification is complex enough without low power, stretching the resources from both a verification productivity standpoint as well as IP cost. When you add low power into the mix, it makes things much worse. The complexity of low-power designs has been going up slowly but steadily. Some companies that are on the cutting edge, particularly in the mobile market, started adopting low-power designs about five or six years ago. They were the frontrunners of the whole low-power wave. They put the initial pressure on low-power verification, because now you have to start thinking about verification differently. You have to start thinking about voltages, multiple supplies, and whether things going to work in all those conditions. Clock gating is the most basic technique, and almost every company you talk with has been doing clock gating. Now that has expanded into more sophisticated techniques to curb the power, and with that comes the burden to verify properly. All it takes is one unverified state or transition or sequence for the design to completely lock up and not function at all.’

LPE: How bad is this problem?
Balachandran: It’s becoming more widespread. There are government regulations and green initiatives. Everything is going green. There are demands on specifications, and even on power for devices connected to the wall. That requires chipmakers to make their designs much more power-efficient. Customers typically start with four or five power domains. Some of that verification can be done with static techniques or with some rudimentary simulation. But it’s becoming more complex, and this complexity is increasing for the mainstream market, not just the mobile market. The number of power domains is exploding. We’ve seen designs with 50 power domains, which is potentially 250 power states. It’s pretty much impossible to verify all of them. So you need to come up with a really good test plan. When people are confronted with low-power designs the first time, they have no clue about how to write a testbench for low power. Often they need a lot of methodology help, in addition to having the right tools in place, to figure out what they’re going to do, how they’re going to go about doing it, and how they know when they’re done. Then, what is the measure of confidence they have at the end to figure out if they’re really done?
Rizzatti: From the perspective of emulation, this technology has been used for functional verification. Ten years ago, power management was essentially a gated clock. You turned off and on some part of the chip and saved energy there. Around 2001-2002, designs with 10 or 20 of these were called derived clocks. Today we have customers with 100,000 derived clocks. There’s an explosion. But that’s only one problem. Over the past five years, and especially in the past one or two, there are all these new techniques for turning on and off voltages. We had one customer with well more than 100 power domains. The whole industry is changing. Power management is a nightmare, and it makes SoC verification orders of magnitude more difficult.

LPE: With a disaggregated supply chain and more IP re-use, does it make it more difficult to verify the design? Not all of the IP is fully characterized for power.
Balachandran: UPF, or IEEE 1801, and CPF have ways to model the power intent of IP. The issue isn’t so much the ability to specify the power intent of IP. Talking to all the major customers, everybody is either integrating internal IP or using third-party IP. Some of the IP blocks have their own power management, too. It has to be communicated to the integrator of that SoC as to what are the legal ways to integrate the IP into the SoC. That information has to be passed along. The power format is not the right way to pass that information. So the industry has to work out a way—together—to solve this problem. The IP companies, the EDA companies and the whole ecosystem has to work on this to facilitate communicating the right behavior that IP can be integrated from a power perspective, and to tell the IP integrator when they are doing something wrong. If IP is coming from a third party and you have no idea what is going on with that IP in terms of its inner functionality or how the power is implemented and what ways you can put it together on the block, then you can shoot yourself in the foot pretty quickly. This is a problem that needs to be solved. One potential solution is to create assertions for an IP block. The IP developer doesn’t know how IP is going to be used, but they do know what is legal or not. They can create assertions for that and ship it with the IP. Then, when the integrator puts it into the SoC and runs the verification, they are able to figure out if they’ve done it properly or not. If it’s not, then they can have a dialog with the IP company. It’s a way of communicating the data sheet of the IP to the next-level integrator. This is one way of solving the problem. It requires close collaboration between IP partners and EDA and design services companies.
Rajendiran: More times than not, people don’t do that. There are many ways that tools can help, too. If some expert designed the IP block, he can provide some input and then a tool can insert assertions back into the RTL. Ideally you want to keep it separate as a companion file. That’s one approach. But the problem is more complex than that when it comes to low-power verification. IP is one issue. There is physical IP where you can’t do much because it’s already hard coded. There’s also soft IP. Each of the classes has its own challenges. With the soft IP, a lot of activity only happens at the gate level. Depending on how the RTL gets synthesized and mapped, you can have a perfectly functioning solution when you use a particular library in a particular foundry, and the same thing may not work somewhere else. You need deep knowledge about this stuff. You need collaboration of tools, the integrator and the IP developer to make sure you at least get the product out to market on time.
Ruby: There is another dimension of IP—the power intent side, which is the functional verification aspect. That’s absolutely essential to ensure the functionality. Time and time again, what I’ve come across is the need for some way to describe the power consumption behavior of IP, as well. It could be technology dependent or technology independent. It could be models that describe assumptions as a function of clock frequency or data rates. From my customer perspective, this is also becoming essential in the power verification area because they’re not just worried about functional intent. They’re also worried about hitting their power specs. They need models for the IP coming in. If they plug IP into their design and they run their clock frequency at a certain rate, what power consumption can they expect? That’s another very important element to this verification challenge.

By Ann Steffora Mutschler
Engineers today spend more than a quarter of their time trying to meet power specifications.

A survey of more than 700 engineers by Calypto illustrates just how important and time-consuming power management is today for engineering teams. As consumer devices grow ever more complex, the need to deal with, analyze and optimize power at not just the RTL but at the system level is the next challenge, even if the path to reach that goal is not yet clear.

The opportunities for optimizing a design for power efficiency are greatest at the architectural level of abstraction. The further a design moves downstream the less effective optimization techniques become, noted Yossi Veller, chief scientist for ESL at Mentor Graphics, in a white paper he co-authored for ARM’s IQ Magazine. “Power optimization must begin with architectural analysis, exploration, and optimization of power and timing at the electronic system level (ESL). According to a study by LSI Logic, techniques available at the RTL synthesis phase have the ability to reduce power by 20%; those at the gate level offer a 10% reduction; while those at the layout level can reduce power by only 5%. Waiting until the RTL to begin optimizing for power is a wasted opportunity because power usage can be reduced by 80% at the ESL.”

“Traditional power optimization tools are really working at the lower levels of abstraction,” explained William Ruby, senior director of RTL power product engineering at Apache Design. “If you look at synthesis, if you look at physical design, there are some automated techniques that are available in those tools. But those are in a category of additional refinement-type steps. Once you have the design architecture nailed down, then you can add in some optimizations based on those tools and you can get some additional incremental power savings, but the part that is missing is enabling the true design-for-power efficiency. If you look at modern chip architectures, they are extremely complex and the RTL descriptions of these architectures are even more complex such that RTL in some cases is no longer seen as a viable architectural description language. You want to be able to describe the architecture of the design in a high level of abstraction.”

With this description comes the requirement to be able to analyze power. Today, this is done by synthesizing the design from a high-level description such as C++ down to RTL, and then an RTL power analysis tool can function and give feedback into the architectural domain. But what needs to accompany this synthesis-loop-back type of flow and give some indication of what the power numbers is more intelligence in those high level tools. They need to point out inefficiencies in a design at both the RTL and architectural levels.

Chris Rowen, CTO and co-founder of Tensilica sees two big challenges for power analysis tools. “One, it is very, very difficult to isolate where the real problem is. It only makes sense to really measure power at the level when you have really synthesized the logic and laid it out and you actually know what the physical design looks like, because the physical design has a huge impact on what the power dissipation of the circuit it.”

By the time it has gone through synthesis and place and route, you have really very little visibility into what was the original logic being questioned. “It all goes into the Cuisinart and all you get is this amorphous mush of gates at the end. So if someone asks you, ‘How much power is being dissipated in my multiplier versus in my divider versus in my register file,’ I don’t know anymore because I have to process them all together in order to get good physical results. But then it all has been aggressively remapped into other logic forms and I can’t isolate the power easily. So you have to work in rather indirect ways to figure out whether the power was being dissipated in one function versus another.”

A second problem, he said, involves system-level tracking of different scenarios. “It is extremely difficult to reach your power goal if you say, ‘Let me use the worst case assumption about each subsystem. I’m going to assume that every piece of my baseband is on, and every piece of my Layer 2 and Layer 3 protocol stack is on, and my image processor is on, and my apps processor is running full out, and all of my RF subsystems are running,’ because of course you’d exceed your power budget by a factor of two or three. Instead people recognize they’re not all on at the same time, the system doesn’t work that way. When you are doing one thing, then you’re typically not doing something else. Therefore, you only have to look at the particular combination of subsystems that is on at that time. However, the software guys have really poor tools to correlate what’s going on in the higher-level operating modes to what’s going on in terms of actual power dissipation in different subsystems. They are completely shooting in the dark where they do not have anything like the kind of accuracy for the modeling of these things.”

As a step towards true system-level power analysis, engineering teams are gradually figuring out that they need to build approximate models of power in addition to simulation environments that are fast enough to run realistic scenarios and to capture real activity. “Ironically getting power information is more than anything else probably a function of getting fast enough simulation, because only if you can run realistic size scenarios will you really gain interesting information,” he said.

This has become one of the big drivers of ESL, which until recently has been relatively slow to catch on. But complexity at advanced nodes, including power considerations, have significantly boosted it’s appeal.

“What the user would like is to have at the very early stages, when he has a TLM model of the design, is at least a relative assessment what architecture decisions will impact the energy in which direction,” said Frank Schirrmeister, group director for product marketing of the system development suite at Cadence. “He will also want to know how the software impacts all of that. From a technology perspective, TLM models allow you to do that so it’s fairly straightforward to annotate power-related data into TLM models,” he asserted.

Annotating models with data just like annotating performance is a challenge and can be approached in three ways:

First, he said, “You can start with your assumptions, with your power budget. TLM models and virtual prototypes allow you to then execute your assumptions so you have in your power envelope/power budget. You say, ‘These tasks should take that much power, I know that from past experience,’ and then you execute your virtual platform with those annotated, estimated data or budgeted data. And you get dynamic results depending on what tasks the software ends up calling, how long a cell phone is used for which task in a day, and so forth.”

Second, annotate back from when you have RTL. “At the RTL level you have these switching formats that you can derive from the RTL to get a good idea about the activity,” Schirrmeister continued.

And third, it can be dealt with at the silicon level by taking previous designs, measuring power information and annotating back into TLM models.

Design engineers are undoubtedly looking for analysis and optimization at the system level so they can do power analysis and power estimation before RTL is available and before they can do gate-level simulations. But are they truly ready to adopt it?

Achim Nohl, technical marketing manager for Synopsys’ solutions group pointed out that today, power analysis starts with gate-level simulation. “If you talk to a hardware engineer and tell him, ‘We are going to employ virtual prototyping and high-level models to do power analysis,’ he will certainly look at you a little strange because he thinks, ‘I’m doing all those back-end optimizations and all those specific things to optimize power. How will you ever be able to reflect that in a virtual prototype simulation?’ But that’s not the point. For virtual prototyping, the granularity of a system is very much different. You’re not looking at just the memory controller. You’re looking at the CPU with the memory controller, the buses, the interconnect, the peripherals and how all those things are orchestrated to find out where the different hot spots are and what is best way to program all those pieces. What is the best scheduling technique? That is the concern at that level.”

When a new chip is architected today, estimates are done to determine whether the chip is feasible at all from a power perspective, he said. “Today, people are using spreadsheets in order to do this analysis, and this can only be a worst case analysis because they don’t know the dynamics and can’t reflect the dynamics of the system in those spreadsheets.”

While the pure architectural level tools don’t exist yet, many users are likely content with high-level synthesis tools for the time being. Apache’s Ruby believes they are good in their own respects but they are not actually meant to give architectural guidance; they are just meant to synthesize the design above the RTL.

One final thought for nervous system architects: The architectural tools of the near future will not replace the actual architect unless they become truly artificial intelligence, which is not likely to happen any time soon, Ruby concluded.

By Ed Sperling
Adding extra circuits and silicon area to a chip has always been frowned upon by chipmakers. Extra silicon means extra money, and for most chips the least expensive is always the better choice. But at advanced process nodes, margin also can slow performance, increase power consumption, and make it harder to achieve timing closure.

The obvious solution is to reduce margin throughout the design, but the reality is that margin budgets for a complex SoC will never go down. The best that design teams can hope for, in fact, is to keep margin constant from node to node and across stacked configurations. While this will require constant vigilance on the part of architects, it also will increase challenges from the conceptual stages of the design all the way to achieving acceptable yields in manufacturing.

What can’t be fixed
In some cases excess margin is out of reach of design teams. With more and more third-party IP now included in designs—and as much as 90% of the design now a combination of third-party and re-used IP—it’s difficult to even get a firm handle on the amount of guard-banding being done. So far, this hasn’t been a problem because most of the industry still isn’t producing 28nm chips in volume.

“Right now it’s only really a worry for the ‘star-IP,’ because if my USB controller is a bit bigger and power hungry than it might be, it is still peanuts compared with the overall platform figures,” said one architect at a large chip company, who spoke on condition that he not be named. “Even the sum of the power of all the little things doesn’t approach the star-IP. And here’s a thing about the star-IP: It may be big and power-hungry, but it there’s still a case for it. Some IP has a well-defined job to do and has to get that job done as efficiently as possible. But with star-IP, it’s mainly ‘faster is better.’ So sure your Web browser would be more power- and area-efficient on a Cortex-A8 than a Cortex-A9, but I bet you’d rather buy the A9-based tablet.”

Those kinds of choices, as well as time-to-market pressures where IP can be re-used quickly, make guard-banding almost inevitable. What’s surprising is not that it still exists, but that it has remained relatively constant given the explosion in the number of components on an SoC.

Where margin matters most
But margin still causes signal propagation issues because there is more silicon and more wires that signals need to be driven through. That, in turn, leads to the need for wider buses.

“When you guard band you need to ratchet up the intended operating frequencies and increase the clock frequency,” said Neil Hand, group marketing director for Cadence’s SoC Realization Group. “All challenges are made worse. In some parts of the design there is no impact. If you have a low-speed peripheral you probably don’t need to worry about it. But with something like high-performance PCI Express, gen 3, you have fast protocols and huge pipes and margin becomes a critical issue. You have a hard time meeting closure even with no margin. Margin makes it worse.”

He said the key is not so much reducing the percentage of guard banding. The rate has been relatively constant, with about 20% margin at 65nm and 90nm, and at least 15% at 28nm and 20nm.

“With that number there’s a lot more slack,” he noted. “You need to know where the slack is and where it’s going to impact the design. Where you do have room to move it may drive different IP use. There may be better IP externally.”

He’s not alone in that view. In fact, all of the Big Three EDA vendors are counting on the need to trim margin to boost their IP sales over internally developed IP blocks.

“There are a lot of challenges working with 28/20nm because of the variability in processes,” said Navraj Nandra, senior director of marketing in Synopsys’ Analog and Mixed Signal IP Solutions Group. “Reducing margin makes a different for getting performance out of analog. You also want to be competitive in price-performance-area. The question is how much margin you can accept in IP to meet those goals but not compromise on yield or variability.”

This becomes a difficult engineering tradeoff, however. Do you design IP for a specific chip, or do you add enough margin to allow it to easily plug into other designs? For commercial IP, the answer is clearly versatility, but there is a cost to that flexibility.

“You can’t be competitive and have slop in the design, but you can’t build something so competitive that it will only work for one design,” Nandra said. “It’s like a drag car where you run it for a half mile and then you have to replace the engine, the tires, and add more nitrous oxide. You can do the same for super high-performance chips for one temperature range and one process, but it’s useless for anything else. The goal is to build in enough circuit techniques with just enough margin not to risk performance problems if there is variability in the process.”

Manufacturability
Process variability has become particularly troublesome at advanced nodes. Coupled with double patterning at 20nm, and the likelihood of triple patterning at 14nm, margin takes on entirely new dimensions.

“We’re trying to characterize process corners and design around a nominal target,” said Jean-Marie Brunet, director of product marketing for model-based DFM and place and route integration at Mentor Graphics. “Third-party integration is a real challenge. Fill used to be a simple process where you insert it at every layer. But you don’t know what is in the IP these days, so fill has to be re-done. That doesn’t help with the integrity of the IP.”

He said that for most IP, there usually is guard-banding on the periphery of the IP to deal with fill. That impacts timing, area and performance.

“This is really an issue for the big chip companies that do 300 to 400 tapeouts a year, not for the microprocessor houses that can take their time to eliminate margin. The problem is there is no magic bullet for everyone else. And when we get into double patterning, this is really going to be an issue because you’re overlaying two masks, and any shift of the overlay will have a dramatic impact on the chip.”

The future
While pressure to reduce guard banding will continue, there is at least some hope for dealing with the problem more effectively. One involves new materials, such as graphene and silicon on insulator, which help reduce power, and new structures such as finFETs and carbon nanotube FETs, which minimize the effects of leakage and thereby make up for some of the power drawn by the extra margin.

A second approach is better tools. Knowing what the variability is in a process allows engineers to design in a minimum amount of margin. Building more accurate models can help, particularly in conjunction with analysis tools for exploring one IP block versus another.

And finally, stacked die will alleviate at least some concerns because portions such as analog can be developed at older nodes where they make more sense, rather than trying to fit everything into the latest process node.