By Pallab Chatterjee
Historically system-level modeling was based on making sure there were no timing crashes on the main data bus. After that it was multi-core conflict resolution, distributed memory routing and, most recently, verifying the correct core actually has access to the correct memory with the data that is relevant being available.

All of these areas are now subject to an additional constraint—power management. The IP-level designer has been pretty lucky so far in that the functionality of the blocks were relatively agnostic about data and mode. The system designer had to verify the blocks would work in those modes, but the IP designer could basically get away with existence, rather than optimization, of the characteristics in the “non-normal” modes.

Designs for the new technology directions do not have this luxury. The new technology is a battery-operated device that communicates by RF to some network-connected appliance, which then sends the information to a high-speed server operating with high-speed storage, interprets the data and then sends some sort of visual/video/multimedia-based response as to what the data meant or did. In this scenario, all of the applications need to be aware of how the data is managed across this series of steps to ensure data interoperability. A recent example is the launch of the IPV6 addressing format, which changes the Web address space to 128 bits from the current 32 bits. Unless devices are tested and verified for compatibility, and memory strictures are reconfigured to use the 4X memory cycle and pattern, there may be issues transferring data to and from the compute processing machines.

Other examples include the 802.3az or Energy Efficient Ethernet protocol (EEE). This allows for multiple power-down and idle state modes for the MAC and PHY of Ethernet connectors between 1G and 100G. In system testing, all of these new modes and the mix/match (back compatibility) modes of these interfaces have to be checked for timing. While finite in number, the variability and combinations are high. This results in not only a cost impact to perform the simulations, but a real challenge to interpret the output.

There are two major impacts in this area. First, the PHY models are primarily in analog mode. These are RF descriptions that do not translate one-to-one to logic simulation models, and hence have a capacity and interpretation limit. Second, at the very high data rates and in combination with the EEE spec, the blocks have a data pattern dependency on what is being sent and their response.

At the 100G level, options such as configuration (4 lanes of 25G or 10 lanes of 10G) significantly impact the design as to what power down and idle modes are in the system. Also in the multi-lane configuration, the adjacency issues associated with noise, IR drop, ground bounce, and other switching characteristics are directly dependent on the data passed through the load balancer. This requires the switch simulation to include a complete model of a high-level system block into the sub-system simulation to determine data validation. These are aspects not normally in system models and verification flows today.

These issues are only getting more aggravated as data patterns shift to application-specific content, which means the data stream that has been used historically (512 byte blocks, continuous stream) is no longer the standard. AF drives are forcing 4K blocks, and video data and APP data (or Java applet) are pushing long data streams and very short (under 1KB) data sets through the net. According to Cisco, more than 60% of traffic is long string video, which is the new default data traffic. Systems verification models need to be updated to reflect these issues before power optimization can be performed.

By Ann Steffora Mutschler
The lithium-ion battery has the power to ruin someone’s day, especially when it dies and cannot be charged, not to mention occasional thermal runaways that literally cause explosions. For a technology that is about 30 years old, and approaching its limits, it is mind-boggling that the best brains on the planet haven’t come up with a technological superior alternative.

But alas, they have not—at least from a realistic cost perspective. While the world waits, electrical engineers and system architects are leveraging power management techniques in the design of chips to do everything they can to make their system as efficient as possible to gain a bit more battery life.

As such, the power management IC industry is healthy. Marijana Vukicevic, principal analyst for power management at IHS iSuppli, predicts the global market for power management semiconductors will reach $36.2 billion in revenue this year, 13.9% higher than $31.8 billion last year. However, she expects growth to slow this year to bring revenues back in line after tremendous growth last year.

This move toward more efficient battery-powered devices is driving continuing demand for power management ICs as consumers everywhere look for longer battery life in their mobile devices—with new design trends likely to emerge in power management ICs, Vukicevic said.

Growth in alternate energy markets, including solar, wind, the electrification of vehicles and the smart grid also will drive growth, along with a move toward greater integration in power ICs. Those suppliers with the technology to further integrate their chips will reap the greatest benefits in terms of revenue.

“There are trends that are pulling several power management ICs into one, which is understandable for some devices,” she said. “Then there are times when some of these functionalities are coming from power management ICs that had already been integrated because the OEMs are looking into having more flexibility or they really want to add a feature that no one else does.”

Understandably, for tablets and iPads, there is a lot of integration because space is restricted and form factor is an issue.

When it comes to techniques, there is always a different issue, she noted. “Whether it is the battery charging, whether people are trying to figure out the best way to charge the battery without damaging the battery because you have to keep the current flowing—there are different techniques that people are applying. Some of these techniques are IP-protected, some of them are not. You do have companies looking into that, of course, because it is a big issue.”

Discrete chip vs. embedded block
In designs today, power management is implemented as discrete devices in a system or as part of the SoC, with the exact breakdown difficult to nail down.

“We have seen both types that are on-chip power management functionality available. There’s a lot of off-chip. It depends if you have a single SoC system. Then the power management has to reside typically on the SoC itself. That would be one reason to put it on the chip,” said Krishna Balachandran, director of product marketing for low-power verification products at Synopsys.

The job of the system architect is challenging. First, before even deciding how to implement the power management, the architect has to determine how to proceed. “There are a plethora of techniques that are available and the architect has to figure out which ones he/she wants and how to partition the design into a number of power domains. So that’s an architectural problem. Even before that, the architects decide how much they want to control power at the system level vs. using software vs. the hardware chip level. That’s a tradeoff they make early on,” he said. “Usually, whatever they are not able to achieve from a system perspective and from a software control perspective, that’s when they start putting the onus on the chip design itself. The system architect goes through a process, figures this out, and then says to the chip design team, ‘You’ve got to deliver me this power for this particular chip.’”

Looking at the smart phone market, there is also a trend toward integration of power management. “There are still functionalities that are outside that one particular IC, but there is a trend of integration because otherwise they would end up with a bunch of different ICs that take up space. Major power functions are integrated with the supporting ones that are not,” Vukicevic said.

The design approach depends on the OEM. “Between OEMs, there is a differentiation on how they do things. For example, sometimes you’ll find an OEM who buys a digital baseband from Qualcomm, for example, and then they buy an analog baseband from Qualcomm, and either power is integrated in that analog baseband or Qualcomm supplies an IC with power management,” she noted.

On the other hand, some OEMs pick and choose how the power is going to be managed. And finally, there is a top layer where software manages power consumption within the device—a layer of firmware and software that is above the hardware, Once you plug in to all of the hardware inside, there is a layer of firmware and a layer of software that is closest to the user, where the user actually can influence power usage, Vukicevic said.

By Ed Sperling

Low-Power Engineering moderated a panel featuring Bhanu Kapoor, president of Mimasic; John Goodenough, director of design technology at ARM; and Prapanna Tiwari, CAE manager at Synopsys. What follows are excerpts of their presentations, as well as the question-and-answer exchange that followed.

Bhanu Kapoor: There are two types of power you need to consider: Dynamic power, which is consumed because you are doing some useful activity, and leakage power, which gets consumed whether you’re doing something or not.

The dynamic power has dependence on switching activity, the frequency, the capacitance and the supply voltage. There are two components of leakage—sub-threshold and gate tunneling. Gate-tunneling is addressed by advances in process technology such as metal gates. Sub-threshold leakage grows exponentially with the decrease in threshold voltage. At 90nm it was significant, at 65nm it was equal to the dynamic power, and it grows from there.

If you look at the typical smart phone, it’s the same system-on-chip that is running different applications. These different modes of operation have different performance requirements. You can use different voltages to achieve those different levels of performance.

A typical power-managed SoC includes a power-management IC that provides different cores. One core can be a processor. And if it’s an ARM Cortex A9, there is power management in that core, as well. A second core might be for mixed signal, which potentially could require higher performance. And then this power controller, which is on all the time.

All of these power techniques have an implication on verification.

If you look at standby leakage, one of techniques is power gating, which is cutting off power to certain regions. If you don’t need portions of the chip to be on, you can completely shut it down. That is power gating. But that has an effect on performance, because turning on and off a function is a long event compared to a clock cycle. You need to sometimes retain the state so you can come up fairly quickly.

All of this has an effect on verification, as you can see from the following chart.

If you can do gate-level simulation, that is very helpful. You need input/ouput and power connected and you need to have appropriately modified your library definitions so power is one of the variables. With domain isolation, once you shut down you have to make sure you are not sending floating values to other regions. You have to isolate it to proper ones and zeros, which you can check with isolation gates using a rule-based checker.

If you have power in your simulation, a lot of rule-based issues can be addressed right up front. Over the years, simulation was not power aware. In the future, simulation will take a more and more important role. Simulation, by default, will incorporate power.

John Goodenough: We are verifying systems on chip. They’re large. They have lots of power domains to match all the application workloads that are going to be demanded on those devices. They have processors and software. Some of the domains are being switched on and off to meet the energy profile. They have virtually every technique available. The state space you’re trying to validate is therefore exploding by an order of magnitude.

One of the things we think about a lot at ARM is that it’s not so much the techniques that you can apply. It’s how you’re going to scale them to tackle these problems. There are lots of clever ways to validate, but not all of them scale effectively into workflows and onto your infrastructure. Power verification is not just about logical verification.

If you get a chip like the one below, you can mess it up in a lot of different ways.

Usually, you can fix it in software. But you also can mess up the connectivity between the power domains. If you get your level shifter or always-on buffer or retention register wired up wrong, it’s not going to work. It’s going to be D.O.A. on the bench. A lot of chip failures are being caused by the failure to verify the integrity of the power network.

That’s a non-standard piece of verification, particularly where that interacts with the logical function of the chip and you’re trying to measure the maximum in-rush current and the average in-rush current. If you’re switching domains on and off, what’s the power domain going to look like from an electrical perspective? Is turning one domain on and turning another domain off going to put the voltages on either side of a level shifter into a pathological state that will damage or degrade the transistors and the level-shifting buffer?

There are some very interesting cross-coverage issues between what is traditionally more of the analog verification space on the power network and the logical verification space. We need, when considering power simulation, to run abstracted analog simulations, SPICE-level simulations, and cross between the two.

Unfortunately, the explosion in power states is also increasing because of the number of software states or the number of field configuration states. From a verification standpoint, not only are you adding a multiplier due to power states, you also have things like a secure or non-secure state. Will they work when a chip is configured for a single package and pinout if it uses another package and pinout? There’s an explosion in these operating modes.

The other pressure we have is making sure you’re going to hit a given schedule. In looking at the power metrics it’s important to see how they can be applied into practical workflows and how you can feed performance metrics from wherever you are in the process back up into reporting and closure reporting. If you combine the need for those two, one of the things it leads to is enterprise scaling, both in terms of infrastructure to support the simulation and how you scale this across workgroups that are not co-located.

The other problem you face is that if you do all of the verification, you’re never going to get the chip out the door. You’ve got to have a verification plan and really narrow down which of the power modes are going to be pathological and which ones can be worked around in software. A major part of thes power verification is the integration of a VP of engineering risk-reduction play into a more mainstream verification practice.

We’ve come a long way in a lot of the techniques, but at the end of the day you have a block diagram that needs to be simulated. Today that block diagram consists of RTL and some way of describing the power network or the power intent and power state space of the design. You also have to support the verification IP and transactors. You need coverage across the RTL and the power descriptions. It’s not rocket science. It’s just a more complicated block diagram.