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

Fig. 1: The ability to optimize power at the architectural far exceeds that at lower levels of abstraction.

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

By Ed Sperling
For the first part of the 20th century mechanical engineering dominated almost everything in technology. For the second half, once the transistor and the integrated circuit became well entrenched, those two disciplines largely divided up the tech market.

More recently, however, they are being forced to collaborate in teams that historically had nothing in common. While the combination of electrical engineering with software has raised questions about how to trade information back and forth, mechanical and electrical engineering arguably are even further apart. But there is at least one consistent element throughout the most recent combination—power.

Power and heat
One of the biggest changes in engineering is that power is global. Physical effects such as heat, electrostatic discharge and leakage current can affect many other levels of a much larger system. That larger system could be a car, an airplane, or a data center.

“Inside of an engineering organization, someone near the top has to worry about the entire system,” said Larry Williams, director of product management for the electronics business unit of Ansys. “They have to think about boundaries between systems and subsystems, or between mechanical engineering and electrical engineering, because many firms are organized that way. When building a system, the optimum design can be found by considering the system as a whole, and additional margin is often found at those boundaries.”

He said that at a meeting within one defense contractor, he actually introduced the mechanical and electrical engineering teams, who had never met even though they worked on the same projects. Those silos have since begun breaking down, in part because systems demand power efficiency, better reliability and lower cost. Things that used to be done as purely mechanical engineering may be mixed together as part of a bigger system.

But the perspective of each is different. Consider thermal budgets, for example. Electrical engineers focus on turning off as much of a chip as possible when it’s not in use, and running what’s in use as efficiently as possible—even going so far as to weigh whether specific operations use less energy when they’re run at maximum speed for short periods of time or slower speeds over longer periods of time. Mechanical engineers, meanwhile, focus in the other direction—cooling the devices as close to the heat generation as possible. In the past, that meant simply drilling holes into metal and adding heat sinks and fans.

“As density has increased it is no longer possible to thermally manage a device around the PCB,” said Robin Bornoff, FloTherm product marketing manager in Mentor Graphics’ Mechanical Analysis Division. “It’s gotten to the point where the mechanical perspective cannot be a separate discipline. We’re now seeing representatives of the thermal design teams showing up right from the beginning in meetings with the system architect. They have to work together.”

That discussion becomes even more critical in 3D stacking, where heat can get trapped between two die. And it’s not just the stacked die that needs to be considered. It’s what’s around it, as well.

“Heat doesn’t obey existing design discipline barriers,” said Bornoff. “The heat will spread into the air, the chassis, the room, and out from there. How hot the silicon gets affects everything, sometimes even outside the building. That’s why you’re starting to see water-cooling in space applications and in data centers. It’s 1,000 times denser than air and 1,000 times better at removing heat.”

The challenge is to get that cooling as close to the source of heat as possible. So rather than just cooling a server cabinet, for example, the liquid is pumped around the processors producing the heat. There is even research under way in microfluidics to pump liquid around the chip itself in a stacked die. Bornoff noted that initial approaches tried to squeeze the fluid through very narrow channels, which required massive pressure. He said the latest research uses piezoelectric fans and pumps, whereby vibration creates movement in the fluid.

Fig. 1: Microfluidics. (Source: Imperial College of London)

MEMS and energy harvesting
Another confluence of mechanical and electrical engineering skills has been the MEMs world—microelectromechanical systems—which are growing in importance in markets ranging from touch screens to smart sensors and analog signal conditioners. There are even micromotors with gears attached to semiconductors.

“Electronics is relatively young compared to mechanical engineering,” said Cary Chin, director of technical marketing for low-power solutions at Synopsys. “But the next big rev of the market is pointed toward electromechanical systems. A lot of these are being looked at for technologies that will start to solve the power problem. With a mechanical system there is no leakage. And for devices that don’t require a really high level of performance, they may be able to power a system forever.”

Think about biomedical devices such as a pacemaker, for example. An energy scavenging system that includes semiconductor technology and mechanical energy harvesting can be used to provide enough power just from a person’s own heartbeat to both keep a steady pace, detect when there is an irregularity, and even act as a defibrillator for one or two stored duty cycles.

Fig. 2: Mini motors. (Source: Sandia National Laboratories)

“The challenge for the tools world will be to rethink optimization,” said Chin. “With power we already had to make significant changes for implementation and verification. Now what we may be looking at is support electronics, where the heavy lifting of computing is moved into the cloud.”

The future
The so-called Internet of things is another big driver in this whole shift to fuse together electrical and mechanical engineering. Within this scheme, systems will be defined as much collectively as individually, much as they are from subsystem to system, with the actual location of computing as distributed along the lines of the Internet.

Within this scheme, there will be many places that mechanical and electrical engineering cross paths, many driven by power, heat, signal integrity and new applications that are just now on the drawing board. For that there will also be new opportunities for tools that can explore tradeoffs of something done mechanically versus electrically, just as those types of tradeoffs are now made for the best kind of IP and processor cores within a given power budget. And as the silos break down, the possibilities are mind-boggling.

Low-Power Engineering talks about how to verify the power portion of semiconductor designs with Krishna Balachandran of Synopsys; Barry Pangrle of Mentor Graphics; Kalar Rajendiran of eSilicon; Will Ruby of Apache Design, and Lauro Rizzatti of Eve-USA.

This white paper introduces the complexity of power management at the software level for mobile devices by means of Linux and Android. The complexity of hardware power management is mirrored in software. A single defect in the power management scheme can have a catastrophic impact on the standby time of a mobile device. We outline how Synopsys Virtual Prototypes address major challenges in the bring-up and validation of power management software. Furthermore, we introduce how virtual prototypes can be used for software-centric power estimation and analysis.

To download this paper, click here.

By Ed Sperling
Power has been elevated from an afterthought to one of the top considerations and tradeoffs in SoC design, edging out performance and area in many cases and in some cases even cost and features.

Tradeoffs in design always change, depending upon what the most pressing concern is among consumers at any time. For decades, performance was always the top of anyone’s list, followed closely by cost. The MIPS and GHz wars made for great competitive marketing. But as devices become more mobile, and as even the largest enterprises focus on energy costs, the reigning king is power. How long does a battery last between charges on a smart phone or a laptop given a normal use case? How may kilowatt hours does it take to run a server?

This isn’t always a clean tradeoff, however. For one thing, some design features require more power, forcing changes in other parts of a design. And in other cases, the lack of any single use model makes it almost impossible to guess how a device will be used. One consumer may rely on voice calls, while another focus on text and still another may play games and stream video.

What stays, what goes
Decisions about what to keep aren’t always simple. Consider an LED TV design, for example. Flattening the screen requires audio enhancement because it’s impossible to get good enough sound out of a TV without playing tricks with the sound. That typically means more post-processing, more codecs, and more energy consumed.

“There are lots of things that can be done to enhance the audio experience,” said Larry Przywara, senior director of multimedia marketing at Tensilica. “The TV designers are space constrained. That requires various volume boosts, equalization and sound widening techniques just to do what they used to do. That’s doable, though, because as algorithms have gotten more complex the SoCs have gotten more powerful.”

Overall, they also use less energy to drive the SoC and the complete system. But sometimes that requires increasing power budgets in one place and decreasing them in another. “The issues in the mobile space are now finding their way into home entertainment,” said Przywara. “With post-processing you need slight modifications in other places to keep a limited power budget.”

In televisions, that energy can come from a variety of places. For example, the current design on some TVs relies on brighter pixels in the middle, where most people focus their eyes, and dimmer pixels on the corners where viewers don’t look.

Making tradeoffs
For both video and audio, the real change is a combination of improved technology and what consumers are willing to live with. Fifteen years ago most audiophiles wouldn’t touch a CD, and even several years ago the focus on quality in DVDs was considered the competitive edge. More people have migrated to the center of the spectrum as CD quality improved and streaming offers vast convenience even if it isn’t high-definition.

“Audio, from a technology standpoint, is not a big deal,” said Cary Chin, director of director of technical marketing for low-power solutions at Synopsys. “The real focus is on video, and today the real question is how you trade off storage with communications. Do you spend more time and energy to compress it or store it? And do you store it locally or in the cloud? As we focus more on portable devices, power and cost are the main factors.”

The other question is just how much power efficiency is enough. A smart phone uses basically the same technology as a tablet, yet the tablet gets significantly longer battery life between charges, while the smart phone needs to be charged every day.

“Tradeoffs are a great way to define area where the technology is evolving,” Chin said. “In digital video you can improve the resolution, but most of the computation and power is spent in compression and decompression. Even with printers, you can print with finer technology but it’s usually more important to lower the cost. Low power is one of the areas that will become critical to all of these decisions over the next 5 to 10 years.”

But even the technology that can command a premium—products from companies such as Apple, high-end graphics from Nvidia, and laptops from Lenovo—haven’t skimped when it comes to saving power.

“The tradeoff is how much energy you use at any time and how much energy you need to accomplish a task,” said Barry Pangrle, solutions architect for low-power design and verification at Mentor Graphics. “In general there will be more dark silicon and more functionality on a chip, but it won’t all be running at the same time.”

One of the more interesting tradeoffs has to do with which processors are used for what functions. Nvidia’s Tegra3 graphics chip, for example, has a four-core graphics engine and a fifth, lower-power and lower-performance chip for less data-intensive tasks.

Features or function
Perhaps the hardest thing to determine is whether to cut features, cut performance, or live with more power consumption when it’s needed. Will Ruby, senior director of RTL power product engineering at Apache Design, said what’s changed is that power is a fundamental requirement, along with features and functions. Engineers have to meet the power spec, even if that means some tradeoffs.

“There are two aspects to a tradeoff,” he said. “One is at the spec level. What features can you add for what performance and power. As more and more people learn how to do low-power design, they will meet or beat specs. Of course that usually means even more aggressive specs in the next design. The second is a spe-level tradeoff. How much time does it take to switch to a different application, for example? If it’s one-tenth of a second that will be a big difference from two-tenths of a second.”

Some tradeoffs also occur on the process side. Do you use older low-power process technology, or do you use the fastest general-purpose process technology and turn a block off as quickly as possible? Or do you dope the channel or swap to fully depleted silicon on insulator substrates?

Conclusion
None of these tradeoffs are fixed. They can be tweaked and tweaked again, because what may be good enough for one market, one group of users or at any point in time may be different somewhere else six months later.

What is significant, though, is just how integral a part power has become in all of these decisions. “The real key is how you can exploit all the possibilities of what you can get with relatively low power,” said Pete Hardee, marketing director at Cadence. “If you’re trying to freeze frame a golf swing in video, you may want to go completely the other way—all the way up to 60 frames per second. If power is the issue, you may want a slower frame rate. And it’s not just about battery life. Reliability is a big headache for customers. The ability of low-power techniques to control the performance profile can increase reliability, too.”

By Ann Steffora Mutschler
While the term “design flow” can be a moving target, there are some specific requirements for a low-power/power-aware tool flow. Looking at this from a high level, where is the industry today, and where is it headed?

There are really two sides to power, which are almost like two sides of the same coin: power consumption and power integrity. And both of those are global, spanning the system and the package and the increasing convergence of both.

“One thing required in this day and age of ever-shrinking product lifecycles is some degree of predictability,” said William Ruby, senior director of RTL power product engineering at Apache Design. “You want to be able to predict early on, when you’re not even halfway finished with the design, what is your power consumption going to be with a reasonable degree of accuracy? What does the thermal picture looks, even spilling over into power integrity? If I can estimate my power, I should be able to also predict some of the power-induced noise considerations, as well. Looking at the power-aware flow from that perspective, early power analysis for the consumption side as well as the power integrity side is really one of the keys here.”

But what about the tools? The back-of-the-napkin or spreadsheet-type calculations worked to a certain extent when things were not very complicated. There needs to be more precision built in. Apache’s answer to this is the RTL power model (RPM) to get better accuracy and more predictability early on. Ruby explained the RTL description allows for a good power number early on, looking at various operating modes. It takes that data into the power integrity side for early chip power integrity analysis. The predictability comes also with the ability to use RPM throughout the design flow to maintain consistency.

Mary Ann White, director of Galaxy power marketing at Synopsys, said various tools exist today that can deal with many aspects of the complete low-power flow. The problem is that systems engineers don’t tend to think about tools in this way. “Just within the implementation flow, there’s verification and implementation, and we find that those engineers don’t exactly talk and work together as easily, so can you imagine what the challenge would be if it went all the way from system-level to somebody that has to deal with manufacturing and then packaging? Even though we tend to provide solutions in those spaces, we find that customers are still very specialized in their very specific areas.”

What engineers want
Krishna Balachandran, director of low-power verification marketing at Synopsys, said to understand what engineering teams really need it helps to segment customers into different buckets. “There are customers that are very advanced in their needs and there are some other customers who have some low-power needs but they kind of know what they are doing—they’ve been doing low-power for longer than the power formats have existed so they’ve evolved with what has happened in terms of power formats and they’ve started using that. Then there are some new customers that are being forced to think about power not because their devices are by themselves low-power, but by virtue of the fact that they are using smaller geometries to reduce the cost and to take advantage of the wafer pricing which can drop. Those customers think that if they drop down to the lower geometries they’ll have to use some power techniques now in their design, because if they don’t then the leakage power becomes unacceptable. So for these reasons some of these customers are coming into the flow and their requirements are very modest. They are almost able to address in an ad hoc way what they have to deal with, rather than by design aiming for lower power chips. There is a whole range of sophistication when it comes to low-power designs and flows. I see that their needs are very different.”

Barry Pangrle, solutions architect for low-power design at Mentor Graphics, said in the future there will be more emphasis on front-end tools. “That will include architectural-level, system-level type stuff, especially hardware/software tools that will allow designers and even software developers to be able to get a better understanding of how the code they are writing impacts the overall power of the products they are developing. You can have really great hardware and if the software doesn’t take advantage of all the capabilities of the hardware, you throw all that effort away.”

Power formats, mixed-signal designs
In the middle part of the flow, one positive step forward last year was that all major EDA vendors came together to pledge their support on the IEEE 1801 power format standard, which should help with tying everything together. More than just the power format support, the underlying methodology is also critical. Qi Wang, technical marketing group director of solutions marketing Cadence, said a converged methodology is still needed—a single power-intent description that can be used in every stage of the design flow to provide consistency.

Overall, he said, it looks as if we have all the pieces of the power-aware design flow, but there’s still a long way to go to address the multi-vendor flow. “Right now we have two formats. Even if we have one format there will still be challenges, but that will play out over the years because at least the whole market on the customer side will be adopting the same power format approach. Right now some of them use CPF, some of them use UPF. The methodology shift is happening. That train has left the station; that will not be changed. It just takes time for the vendors to work out this multi-vendor flow.”

However, he pointed out, there still are technical areas that need more investment. “One big important thing is in the area of mixed-signal design. If you look at all the hard products right now, it’s all about mixed-signal and low power: you have a mobile application, you want to access everywhere, you have wireless, you have Wi-Fi here and there. It’s all about a mobile and battery powered. This means low power and mixed signal. Customers have combined these together. The technologies need to be combined, as well.”

Another key area is verification. Erich Marschner, product marketing manager for functional verification at Mentor Graphics said, “The verification aspects of low power are largely related to methodology because of the capabilities in the tools have been developed over the last four or five years to model the effects of low power, power management and active power management. Users are still behind the curve in terms of trying to understand what to do with those capabilities. Most of the low power simulations that are done today are still done in the context of UPF 1.0 – the previous version of the standard.”

In this regard, many users still have a way to go to take full advantage of the technology available today.

By Ann Steffora Mutschler
The interplay of hardware and software is a given in every device that contains a semiconductor chip, but is typically felt more acutely in communications applications given the extremely close dependencies for everything power-related. Managing power in these situations just gets more challenging as consumers demand more and better applications on their tablets, smartphones and other mobile devices.

Power is always one of those things that needs to be addressed at many levels simultaneously because there are both raw technology factors: the semiconductor technology as well as system issues—what algorithms you run, what is the collaboration that takes place between handset and base station, stressed Chris Rowen, CTO of Tensilica. “All of this can have significant effects on what the total energy consumption is of the system. As you go up in the level of abstraction you move away from the individual transistors and talk about what the system behavior is, so you can get larger and larger relative savings.”

This is because if the system can be organized such that no communication is required, or one bit of information tells the whole story, then gigabytes of information may not have to be moved across the network, he said. The problem is that the engineering team must know exactly what single bit tells the story. “There are many things that people do in finding ways to store data instead of communicate data, to encode data more cleverly, to make data communication more resilient so that they can avoid doing work, avoid doing communication processing and therefore save lots of power because the radio never has to go on, or has to go on very infrequently and the encoding can be greatly simplified.”

“At the other end of the spectrum,” Rowen continued, “there are many things that you can at the level of the circuit design, the logic design, the processing architecture, which can significantly reduce the power as well—even once you accept that certain standards and certain communications protocols can be used and the intelligent chip architect or system architect is aware of when they have to live within the ground rules of the standard that they are implementing.”

Techniques for saving power
From a software perspective, power-saving techniques are being driven by emerging new architectures, such as ARM’s big.LITTLE, which is where there is a companionship that is able to take over the system when there are low-performance requirement and high-energy requirements, and there are high-performance requirements and faster CPUs, said Achim Nohl, technical marketing manager for Synopsys’ solutions group. Within this approach is the new concept of switching from—on a very coarse grain level—a high-performance, high-energy profile CPU to a low-performance, low-energy footprint CPU.

“At the same time,” he said, “there is an orthogonal technique for power saving—dynamic voltage and frequency scaling (DVFS) where in parallel to big.LITTLE you are able to scale down the frequency of a cluster or of a single CPU. That can only be done by predicting what the performance requirements are for the specific workload to perform a just-in-time completion of a specific task. I need to know how much processing power will be required in order to satisfy this task so that it can be computed just-in-time.”

There’s a lot of impact on the software and on the whole workload prediction. Schedulers must become power-aware. There is also a contrasting scheme called “race to idle,” where rather than scaling voltage and frequency you run as fast as possible and then remain in idle mode as long as possible. But these solutions are hard to evaluate against each other because they are highly scenario-dependent. Scenario means the software and the whole user scenario, Nohl said.

Rowen pointed out a hardware technique for power savings that is gaining steam is the more careful adaptation of the processor engines to fit the tasks, because there are very distinctive things that you do in some parts of the receiver such as FFTs, while in other parts there is a lot of filtering, and in other parts there is forward error correction, which is a successive approximation method for determining what the signal was.

For those at the sharp end of silicon platforms for mobile devices, Pete Hardee, director of solutions marketing at Cadence observed that semiconductor and systems companies are seeking all the power saving techniques they can get. “This is where people have been using the regular techniques like power shut-off. We’re going to see, as well as power shut-off, a lot more use of DVFS – that’s certainly going to be seen a lot more as people struggle with power.”

One interesting technique as designs go from node to node is substrate biasing, which has been used effectively at earlier nodes like 90nm. “Once you get under 90nm there is a lot of debate as to whether or not substrate biasing is an effective technique or not. It is applying a negative bias to the body of the silicon, which reduces leakage especially when you’re at near-threshold voltages. We see substrate biasing being used even at very deep submicron, especially in relation to standby modes of memories that reduce leakage. [But] there is a lot of debate on the effectiveness of substrate biasing beyond standby mode of memories and the reason is there’s a routing issue that all of these bias signals. Per transistor, you’re effectively supplying a bias supply to each transistor of the chip so that gets very expensive from the power routing point of view and you start to hit routing congestion and so on. We see people using substrate biasing at the 40nm node and then it gets a lot fewer at 28nm and people are starting to wonder if its going to be effective at 20nm (22nm for Intel). One thing that we’re figuring out is that finFET probably obviates the need for substrate biasing. You’ve got a lot better control of leakage due to the topology of the gates through the 3D construction of the finFET transistors. When finFET becomes the norm, we think we’ll see the end of substrate biasing as a technique.”

Intersection of low power and test
While test is not so much an area where much can be done at this point to help save power, it is nonetheless an important part of the design process with unique issues, noted Greg Aldrich, director of marketing for the Silicon Test Systems group at Mentor Graphics. “The two aspects that we have to deal with for low power are first, when we are inserting structures into the design, are we consistent with all of the power intent or are we respecting all of the power intent, the power island and what is required for the low power design when we are inserting logic? Are we making sure that, for example, when we are inserting compression logic into a design that may have three or four different power island or power partitions that we’re not crossing those power partitions with the test logic that we insert or that we’re properly isolating those power partitions. If there’s a constraint in the low-power design where I can’t power up all of the three partitions at the same time, I need to be able to test it in that manner, as well.”

The second and, he said, maybe more concerning issue is then when testing a low-power design the tests cannot overstress the power design. “If it’s a low-power design, typically that means that there is very little switching activity, a lot of the design is turned off and the power rails, the power system is designed that way. When you do testing typically you want to get as much activity as quickly as possible so that you can test the device as quickly. You’re testing every single device you manufacture, so every second you spend testing that device costs you more money in the manufacturing cycle.”

In test the objective has always been to get as much activity in the circuit as possible in order to test it as fast as possible, but for low-power designs that approach could damage the device.

At the end of the day, the biggest problem in looking to save power in communications applications, according to Marc Serughetti, director of product marketing for virtual prototyping at Synopsys. “It’s not about hardware, it’s not about software. It’s about the two together, and when it comes to software it’s not about the low-level software either, it’s about the entire software stack because a simple application can create a significant problem when it comes to power consumption. Now you are talking two different worlds once again colliding, and if you approach this purely from a hardware perspective you are going to end up in situation that may sound interesting for the hardware people, but when it comes to the software world where you need to be able to run Android or Windows Mobile, the performance of the environment you need to use are a significant component that must be analyzed.”

What makes one smart phone last longer on a charge than another? The answer may surprise you. Low-Power Engineering talks with Cary Chin, director of technical marketing for low-power solutions at Synopsys, about what his months of research have shown.