Burn, Baby, Burn

Obviously, software burns power on mobile devices, but exactly how? I found out recently, thanks to Pete Hardee, director of solutions marketing at Cadence Design Systems.

Essentially, Hardee said, there are four ways that software burns power, following in order from most to least.

First, depending on the mode, various peripherals are on and off and the big one for a smartphone is the LCD screen. “We’ve all got wonderful high-resolution LCD screens. When you’ve got that thing fully powered up you’ve probably noticed there are a number of brightness levels such that for a while it will dim. The LCD screen is a big one, but turning peripherals on an off is under software control, depending on what you are actually doing with the device is probably number one,” he said.

The second way is how memory is used. “If you talk to any designer of these devices they’re interested in a couple of things related to memory. One is how to efficiently use the cache. Do they have to write cache algorithm for the application? The more data-intensive the application, the more important it is to have an efficient cache algorithm, and associated cache. ‘Least recently used’ (LRU) is one of the common algorithms for cache, but basically finding the right algorithm that matches the data intensive applications that you’re running and sizing the cache appropriately to avoid cache misses is a big thing.”

In terms of cache misses, if the data needed is not residing in cache, it becomes enormously expensive, power-wise, to go get it from the L2 memory or, worse still, the L3. “That is a memory transaction that will burn maybe 100X more power than getting it from L1,” he said. So how efficiently the cache is used is a big deal.

Another issue that comes in here is how well the memory controller is designed, because if areas of the main memory are not used then they tend to be powered down page by page, so a power-efficient memory controller will drop the various pages of memory that haven’t been accessed for a while and power down. Again, that is very interactive with what the application software is actually doing.

The third way software burns power is on the rest of the chip. “Leakage is a huge deal, especially when you are at the 40 to 45 nm node, but it will be even huger for the next round of devices that are coming out on 28nm. Shutting off the circuitry is really the only way to stop leakage—but that has a price,” he explained. There is an overhead in shutting off parts of the chip and bringing them back on so engineers need to make sure its being done effectively. Engineers should make sure that they are monitoring the power modes and the way that the software is running on the device to determine if it’s worthwhile shutting down various circuitry for a period of time.

Finally, software burns power in the processor core itself. One technique used to manage this is dynamic voltage and frequency scaling (DVFS), which monitors the software and the performance that’s needed and reduces the clock frequency and the voltage in combination to play a tradeoff.

“If you’ve got lower performance needs we can actually run slower and run at a lower voltage and take a little bit longer to do the computation but burn less power,” Hardee said. “But here is the interesting thing—when you do that in combination with power shut off, because DVFS will primarily save on dynamic power, but power shut off is primarily to save leakage, there has to be a period of inactivity to take advantage of power shut off. What we are seeing is that the old adage that ‘it’s a performance/power trade-off’ and I want to slow down the computation—there are circumstances where you want to do exactly the reverse and I may want to process the data as quick as I can to enable me to shut off for longer periods. So it depends on how bursty the data is, in whatever you are doing, be it Internet access where you want really quick rendering of the page and then maybe you’re doing nothing for a while. That would be a circumstance where rendering the page as fast as you can and then shutting down for longer periods could actually be a much better approach for better user experience and lower power.”

~Ann Steffora Mutschler