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: Are we seeing a blurring of the lines between design teams because of the shift to more third-party IP?
Hand: Customers want off-the-shelf IP. But it’s a very big distinction between becoming part of their design team and working with them all the way through, versus working on an outsourced basis. Customers want predictable, proven IP.
Butler: It may take a month to deliver the library, and then there are all kinds of bugs. So you don’t ship the library anymore. You work in a common environment.
Hand: Most customers don’t have to deal with that level. But the changes you make to hard IP should be zero.
Nandra: In terms of the feature sets and configurations, when it comes to physical IP it’s a well defined set. The work is done by the IP vendor. They’re proving it on silicon. And then what we ship is a black box.

LPE: Isn’t all IP a black box?
Nandra: The softer it gets, the more configurations customers expect.
Hand: With soft IP such as a memory compiler, you essentially have a compiler for that memory compiler. It’s still delivered as code to a customer. They have to do the implementation, so it’s more of a gray box.

LPE: But the trend is still away from touching that, right?
Hand: You still need to go through the physical implementation. You need to take their design context and optimize it or you won’t be able to hit the power, performance and area targets.
Goodenough: You need to supply the IP with the recipe to get people to the context. We provide soft IP and we provide the recipe to go through an implementation flow.
Nandra: The customer touches the IP, but the goal is to configure it.
Goodenough: They’re touching it in a carefully constrained way.
Hand: Some of these IP blocks have a huge number of configurations, so no two deliverables will be exactly the same.
Butler: And you don’t want to create part numbers for these things. It’s better to ship the IP with the tool that helps configure the IP.

LPE: One of the evolving trends in design these days is more rationalized use of resources—only what’s needed. A second trend is to do more exploration, comparing different IP and different implementations. Are those trends in sync?
Hand: It depends on the risk associated with configurability. On soft IP they want configurability because there’s a lower perceived risk. There will be some parts where if you touch the core there’s too much risk. There’s always a tradeoff between configurability and risk.
Goodenough: If you look at an ARM core, we’ll let people modify that cache sizes and take a gross functional block and turn a SIMD accelerator on and off. If you go and play with a new bus topology for an SoC, you have to go validate it, but there’s a lower perceived risk around that. One trend we do see, which our customers are pushing, is to provide larger subsystems. It’s not just the core, but a core and a memory subsystem that’s ready to go out with software that is known to run on it, including the BIG.little switches. They can adopt the correct risk profile that they want.

LPE: That’s basically managing context internally, right?
Goodenough: Yes. The amount of effort are putting into validation, whether it’s logical validation of systems or signoff, or going through the implementation floorplans, they’re equating time to market with something that is known good.
Hand: Unless there’s a material impact. Your customers want to focus on their differentiation. If you can give them something that’s proven and working and not going to impact their differentiation, they’ll take it as it is. If they can turn a knob and lower power, then they want that knob to turn. If you look at SoCs today, about 80% of them are the same. What’s different is how they’re configured, how they’re balanced and how they’re mapped to their customer application. That’s the secret sauce they bring to the table.

LPE: What happens to the IP industry if we’re pushing into larger and larger subsystems that are more contextually aware?
Hand: There will be increasing consolidation. The cost associated with building IP is going up. You can’t bring a small piece of IP to market that people that people will bank on for a 28nm or 20nm chip. That will be a natural process of maturing of the industry.
Goodenough: I agree. It’s a scale problem—the number of people you’re trying to supply while staying on the edge of physics and software. Only a company of scale can do that?
Butler: But the cost of entry for startups is down.
Goodenough: Yes, and you can still do an IP model as a one-off for one company because your context is constrained. You can still see a lot of innovation where there is a constrained problem. The question is how you scale from one to many. That’s a challenge for the classic IP industry.
Hand: It’s similar to what happened in core EDA. Everyone said EDA startups were dead because it wasn’t scalable. EDA startups continue to happen, but once it gets to a point of scale if it’s rival technology then one of the larger EDA companies acquires them. It will be similar for IP. Once it becomes viable and needs scale, either they become a major player with a large investment—something that’s unlikely—or they will be bought up by another company.
Nandra: We se a lot of companies that want to go to a complete chip, and through that process realize they have a lot of valuable IP. They get on the radar of other companies that need that sort of function. Most companies don’t start out as IP companies. They start out doing design services or with aspirations of becoming a chip company, and through that process they build a lot of interesting functions that are valuable to other people.
Goodenough: You see a lot of technical innovation in function.
Hand: If you look at interface IP, that’s one area where there has been a lot of consolidation. Five years ago there were a lot more companies doing standards-based IP. That’s shrinking rapidly. But there are other areas where there isn’t the level of standardization, such as analog front ends. There is a lot of innovation there.
Butler: OpenAccess was a good way of bring EDA vendors onto a single platform. That drove innovation because it meant startups could be on the same database as Cadence and Synopsys and it was easier to plug their tools in. Will there be something similar in the IP world?
Goodenough: That was the original idea behind IP-XACT, which is a meta-data standard. There are some very successful things being done off the back of that, such as the ability to define register maps and take a lot of pain out of integration. IP-XACT is necessary but not sufficient by itself. You need other standards to glue the Legos together. But you also need to put your glue into a modeling environment. Which one do you use? Which synthesis flow do you use? There is diversity, which is legitimately driven because people are trying to optimize design points and cost structures.
Hand: And a big piece of that is defining a quality standard. What is an acceptable quality for IP and how do you measure that? If customers can’t quantify something it’s seen as a risk. As you going forward, the lack of a well-defined quality standard for smaller companies makes it hard to prove to their customers that it’s worth buying.
Butler: Quality is an intangible thing. It’s not clear you’ll ever define it.
Goodenough: And there is no standard integration environment. Putting a standard definition of quality is nearly impossible.
Hand: But even if you solve all those modeling and integration problems, there’s still a question—if you’re a smaller player—how do you prove the quality of what you’ve got.
Goodenough: It’s a business-to-business transaction.
Hand: But then you have a small company dealing with a large company, which is putting its whole future up for grabs based on a piece of unproven IP. How do you prove it? As a small company, that’s a big problem.
Goodenough: That’s back to the trust issue. You trust the guy doing the IP because you’ve worked together for 20 years and they’ve done this before. ARM is a trusted company. We’ll stand behind it, no matter what it takes.
Hand: But it’s easier for ARM, Synopsys or Cadence to build that trust than three or four guys doing consulting and working in a shed.
Nandra: Most of the customers willing to take on a bigger risk are driven by cost. The actual cost is always more because something inevitably goes wrong.

LPE: A lot of this started with very standardized pieces. Those are no longer so standard. Are there new markets shaping up for IP?
Nandra: The biggest growth is in smartphones and tablets. These customers are driving the smaller technology nodes, and there’s lots of innovation at the fabs to get devices to work at these small feature sizes. There’s a combination happening between baseband chips and application processors. Customers are looking at combining the two. That makes a huge SoC, and we all have to work in technology that isn’t very friendly.
Butler: We see the blurring of boundaries. When a company is looking to interface with a vendor on the bleeding edge, there are so many revisions and so much churn as they nail down what the IP needs to be that they need to have a different way of interacting with a customer. Just downloading something from the Web site doesn’t work anymore. You need visibility into the customer’s environment and visibility into regressions in the test environment. One vendor has set up a portal to give their customers visibility into the IP that’s being generated. That way the customers can figure out if the vendor is on track to have something within the promised four weeks or six weeks. It’s having a way to bring the two teams together and build trust, without having to be on site or have VPN access, and be able to abstract out the quality and the progress is happening.
Goodenough: This is trust and concurrent engineering.

By Ed Sperling
The trend in IC design—particularly for large, complex SoCs—is specialization among engineers. There are specialists for layout, for verification, for DFM, for test, and for software, among other things. And there are experts who have a smattering of many of the pieces and can oversee the integration and testing.

Power is different. Because power affects every part of a design, and it has to be dealt with at every step along the way—from initial architecture to final signoff—there is no single expert or even group of experts who can handle that task. In short, everyone needs at least some expertise in this area, while some may need lots of expertise.

“What’s different about power is that it is still a relatively new focus for most people,” said Cary Chin, director of technical marketing for low-power solutions at Synopsys. “It’s also not compartmentalized. And it permeates what every engineer does. It’s not clear it will stay that way. In the past, things that were not compartmentalized eventually were compartmentalized and automated. But over the next three to five years, it certainly looks as if it will stay that way.”

Part of the reason for this has to do with a lack of automation. At this point, there isn’t even a clear-cut way to automate power. While everyone is well aware of battery life, there is no single fix. There are a variety of models being developed that can at least allow architects and design engineers to take accurate readings and make tradeoffs. And those kinds of models do help on the verification side. But truly automating power will require many more steps.

Compounding that is a lack of understanding about how to deal with power. There are gaps in expertise everywhere, and thorny tradeoffs that no one wants to touch.

“Even though power is getting more visibility, there is still a lack of expertise,” said Qi Wang, technical marketing group director for low power and mixed signal at Cadence. “Many customers want to add low-power techniques into their designs but they’re not aware of the obstacles. If you save power you may sacrifice area and timing. It may impact the design schedule. And verification gets harder.”

He noted that globalization is helping somewhat, because big companies do have a fair amount of expertise in this area.

“The rate of growth of expertise in this area is phenomenal in places like China,” he said. “Three or four years ago, people didn’t know what I was talking about. That’s all changed. With companies like Huawei, and other big companies moving their designs there, the rate of producing experts in this area is improving.”

Different vantage points
Who’s proficient at proficient at power and who isn’t frequently is a function of where they’re coming from within the design space. Some people have to deal with power because their designs demand it. Others don’t—at least not yet.

“The level of sophistication on power is quite varied, and the perspective of system makers is often quite different from the view of component makers,” said Chris Rowen, chief technology officer at Tensilica. “Some teams play it strictly by the book—just look at the specs of all the components, add up all the power, divide by battery capacity, and struggle with the answer. They may always not appreciate either the central role of scenario analysis and software-driven power management in making mobile devices battery life and thermal issues tractable. At the same time, some also have gotten a deep appreciation of some subtle issues around power. For example, the leakage current of 45nm and 28nm digital circuits is actually not bad under typical conditions—room temperature and average processing—and only a small fraction of the active power at normal clock frequencies.”

But only small changes in temperature or other random variances produce non-linear effects that can greatly exacerbate leakage. Rowen said some engineers have been burned by these surprises and are starting to invest much more to avoid them.

Field tests
It also helps that consumers are becoming much more savvy about power. They can set preferences on their phones to minimize power consumption, and increasingly understand that bad reception can sap battery power as a device attempts to communicate to find a better signal. They also can spot a problem and communicate about it over the Internet.

That’s exactly what happened with Apple’s iOS 5 operating system. The newest release includes changes to improve battery life. What makes this particularly interesting for the SoC design world is that Apple is a true integrated device manufacturer. It designs the chip, the software that runs on it, the interfaces for the applications that run on top of all of that, as well as the overall platform. In fact if anyone can get it right, it should be Apple. Still, the complexity of a device like an iPhone or an iPad has surpassed even the most advanced technology companies, however.

“It’s really hard to tell where the problem is,” said Chin. “But these days beta testing is happening at the user level. The problems are so complex that companies need population data to determine the problem. Luckily, connected devices continually gather that information. Apple can gather information from 250 million users in the first week of release. If you were to do system-level simulations, how much can you really simulate in six months? We’re seeing public beta testing for that.”

In this case, users actually became part of the expertise needed to test the power on the iPhone—and an extension of the power verification team at Apple.

Short-term and long-term
While this is an interesting development in power verification, most ICs sold into a socket don’t have this luxury. They have to work well, and they have to be competitive from a power, performance and area/cost perspective. They also have to be delivered on time with increasing complexity, meaning everyone in the design chain will need to know something about power, and some engineers will have to know a lot about power.

While some of that expertise may be automated in the future, experts will still be required to solve thorny issues involving power and related issues such as heat for many years to come.

“Low power expertise won’t necessarily secure you a job, but in whatever you do, low power expertise will help you do your job better,” said Wang.

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.

By Ann Steffora Mutschler
Complete and exhaustive verification of low-power designs requires a substantial effort and part of this includes running real applications on the hardware. Simulators fall short as designers realize that the so-called testbenches they create are artificial and don’t necessarily represent typical applications. As such, this is the sweet spot for emulators, also known as hardware accelerators, in the overall verification environment.

While it sounds like a straightforward approach, this industry segment has been anything but.

Hardware emulation was invented as a means to connect a yet-to-be-built chip—the design under test or DUT—to the target system (the testbench) where the silicon chip will eventually play. “This configuration supports testing with live data to some extent,” said Lauro Rizzatti, vice president of marketing and general manager of EVE-USA. “Since the emulation system runs at a lower speed than the real silicon, you have to buffer the two speed domains to avoid losing data via a speed-rate adapter. When an emulation system is deployed this way, the setup is called in-circuit emulation (ICE).”

Connected to this, speed-rate adapters were developed by each emulation provider and typically they were not compatible. Then, around 2000, Ikos Systems introduced the notion of synthesizable transactors used for emulation. The company was acquired by Mentor Graphics in 2002.

The Standard Co-Emulation Modeling Interface (SCE-MI) was first introduced at that time as a way to standardize the communication between the hardware portion running in the emulator and the software portion running in the PC of a transactor.

SCE-MI1 is the equivalent of the “data link layer” of the International Standard Organization’s Open System Interconnect (ISO/OSI) model for networking protocols. SCE-MI2, at best, is the equivalent of the “transport layer,” although all the complexity of a transactor resides in the equivalent of the top three layers, Rizzatti said.

“SCE-MI2.0 raised the abstraction level of the communication scheme between the hardware and software (using mainly DPI calls between C and SV). But it still did not address the way hardware and software were developed to create the fully synthesizable transactors, and ultimately failed to address the way transactors were simply used in a C or a SV testbench. SCE-MI2.0 does not guarantee any compatibility between platforms. No other layers are defined by SCE-MI. This is probably the biggest challenge, since the communication layer is actually defined in the SV standard with DPI,” he pointed out.

Rizzatti compared transactors with verification IP (VIP) for complex software and hardware. There is no standard to create VIP, whether it is synthesizable (transactors) or not. For example, VIP from Cadence is unlikely to be compatible with VIP from Synopsys, despite complaints from large customers.

“There are two levels of transaction issues here,” explained Erich Marschner, product manager for Questa Power Aware Verification at Mentor Graphics. “One is the transactor that maps from records representing transactions to pin wiggles on the bus. This generally involves code that is synthesizable and therefore can be loaded onto an emulator. There shouldn’t really be any reason why you can’t share that kind of code between different emulators from different sources because it is basically the same as what you would run in simulation. As far as I know most of the VIP that we provide and that others provide, at least if it’s open source, can run on any simulator.”

The problem is sending a collection of transactions from the host to the emulator to be executed on the DUT side. That requires a connection between the host and emulator, and it may differ from one vendor to another. “There is a hardware connection there that is being negotiated and that is almost certainly dependent upon the kind of emulator you are dealing with,” Marschner said.

It’s important to understand that it takes no less than few weeks all the way to years to develop synthesizable transactors, depending on the complexity of the protocol. The UART is a simple transactor while the PCIe is a very complex transactor. Each and every company cannot afford such a large investment , which is the reason why the emulation providers need to offer a catalog of transactors, Rizzatti said.

“While it’s not realistic to ask competitors to work together to make the transactors fully compatible, one possibility would be at least to ask them to normalize the API level of each transactor (for each protocol) so that the customers could re-use the same C or SV test bench for different emulation platforms,” he added.

Different companies have different mindsets of what the API could be. Michael Young, director of product marketing for the Palladium product group at Cadence, related the situation to a software giant. “If you look at Microsoft and the API that they offer, in the beginning maybe they have 100 API calls. Now we are talking about thousands. So, can we do that? We can probably do that, but over time each API becomes a customization of a particular environment of all customers. The minimum thing that we want to give the customer is the flexibility and the knobs that they need to create the environments for the best productivity that they can achieve. What we overlay on top of that is what we call the accelerated VIP that would be a pre-cooked, off-the-shelf kind of solution for a particular protocol, so whether it is AXI, AHB or PCI Express, those things will be off the shelf. Then we would give them knobs within that.”

He added that everyone is trying to standardize this, but that’s not so easy.

“The difficulty is really more of a personality than style. Specific preferences become very difficult to resolve when you have multiple companies trying to optimize it from their perspective. Some of the customers that we talk to are looking for some transportability. I think over time the industry will mature and as we participate in the SCE-MI committee those items will try to cover that in the near term as well as the long term,” he concluded.

By Ed Sperling
Talk with any large systems vendor about power modeling and, with very few exceptions, they’re still using a mix of spreadsheets and lower-level models—no matter how far along they are in ESL adoption and in modeling other parts of an IC.

Power has crept up on even the biggest companies, which have never really figured out how to implement it into their design flows. For one thing, the tools are still evolving. But so is an understanding of how to effectively deal with it.

Smaller companies, meanwhile, are just getting a taste of how challenging this can be as 65nm and 40nm become mainstream process nodes. Density, shrinkage, and competitive requirements have made power a critical issue, and while many are used to dealing with power gating and multiple power domains, the complexity of multiple voltage islands, multiple states between on and off and different strategies for maximizing energy efficiency add a mind-boggling array of choices and complexity to designs.

It’s well known among companies in the mobile IC market—those that have the greatest history of dealing with power issues—that power has to be dealt with at the architectural level. What is less well known is that it requires adjustments throughout the design cycle, and the tools even the most advanced companies are using are a direct reflection of that.

“The only reliable level for measuring power has been the gate level,” said Barry Pangrle, a solutions architect for low-power design at Mentor Graphics. “Above that it’s a relative measure. But to take advantage of the 80% impact on power that you can have at the architectural level you want to take advantage of everything you can. For that most customers are still using spreadsheets.”

This approach has worked fine so far. Modeling can be done on spreadsheets as well as being automated. The problem is that it can’t be updated easily, and there’s no way of testing that the numbers are realistic as the design progresses. “You really want a sanity check throughout the flow,” Pangrle noted. “You estimated the block and you need to make sure it’s right.”

What if…
The lack of automation causes other problems, as well. Because most flows are automated to some extent, being able to update various parts throughout the design process are critical. Virtual models, for example, allow changes in software to be reflected in hardware. But updating models manually with a spreadsheet is cumbersome, made worse by the fact that the amount of data that needs to be added and updated on a regular basis is ballooning. Some libraries are now measured in terabytes.

“At 28nm and 20nm, you’ve got to start dealing with electromigration and other effects caused by heat,” said Aveek Sarkar, vice president of product engineering and support at Apache Design. “You need to create models to capture all of these effects, but these models also have to be consistent and they have to replicate what’s really going on at the electrical or mechanical level. You need to understand the parasitics using linear and non-linear models, and then abstract from there.”

Getting those models right is no simple task. And what happens when an IP block is replaced with another IP block, or a signal is rerouted from one memory to another?

“You need chip models that create power models,” said Sarkar. “That’s one of the top integration focus areas according to feedback we’ve received from system design houses.”

Power everywhere
But is one power model really enough? Power is a global issue, and it affects everything from the software that’s written to a virtual platform to the IP blocks that are being integrated into a design. There are two diverging issues. One is that the classic divide-and-conquer strategy is essential for being able to design and verify complex chips. The second is that power budgets need to be fixed, and they can be affected by everything from those individual blocks to the way they are integrated and used.

“Power modeling is key,” said Philippe Magarshack, group vice president for technology R&D at STMicroelectronics. “Otherwise we will never be able to tackle designs going forward.”

He noted that ST has been using dynamic voltage scaling for several process nodes, along with dynamic voltage frequency scaling. Power islands are well understood, as well. But automating the power remains a challenge.

“There are no standards for this,” noted Ghislain Kaiser, CEO of Docea Power. “This is a problem because we need a common way to capture this data and have the same kind of modeling. The most important thing is to get power models into the design flow.”

And because power generates heat, primarily through leakage, thermal models need to be developed in sync with those power models—something that will become critical as stacking of die becomes more mainstream over the next few years.

But internally developed spreadsheets have reached their limit for adding new data. There literally are no rows and columns left for more data. And existing TLM 2.0 models are too far removed from the power/heat to be useful.

“An accurate power model should have no more than a 5% error,” said Kaiser. “That way it can be used to speed up the debug of power management software.”

Power continuity
Another reason for automating power goes well beyond just the technical capabilities of the tools. It has to do with the way designs are created. Designs have become so complex that even the best and brightest engineers can no longer comprehend the whole design.

“What this means is that you may have an issue in power and not even know about it,” said Qi Wang, technical marketing group director for low power and mixed signal at Cadence. “Verification will become a very big challenge in the future. We’re used to doing functional verification. But power verification to measure power consumption needs to be considered, as well.”

In addition, he said that each step along the way of a design, starting with placement, clock tree and routing, need to be optimized for power. That, in turn, needs to be reflected back into other models that have been developed because the changes can affect all parts of the design.

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