Powering Forward Or Moon Walking?

By Frank Ferro
How many of us would go back to watching television in black and white, or carry around a 10-pound laptop or cell phone that resembles the ones in original brick form? For most consumers, it would even be hard to turn back the clock on more recent innovations like Wi-Fi and digital cameras (finding a place to plug-in the lap, run wires through the house, carrying around film! File that under U-G-H!!

But we as consumers don’t seem to mind reverting to the early days of cell phones to have the latest smart phone features. What aspect of this reversion, you ask? The Big “B”—battery life. Remember your first analog phone that had a half-day’s worth of battery life? To solve this problem, major cell phone companies demanded that your baseband chips support 170 hours of battery life (about one week) in standby mode and about five to seven hours of talk time. The good news was that these talk and standby times were actually achieved! Basic feature phones will easily last a week in standby mode.

But today I feel like I am back to the early days of cell phones. I need to charge the phone every day and constantly watch the power meter. There’s even a new twist. I need to turn off applications that reduce my battery life. File that under high maintenance. However, I will say, that standby time in some smart phones is not too bad—two to three days, providing you don’t use them!

So with all this talk about “power-aware” designs, where’s the progress? Clearly the need to have big touch screen displays with at least three radios in your phone (cellular, Wi-Fi, Bluetooth) is outpacing power-efficient designs. And then add the fact that leakage current gets worse as SoCs move to smaller process nodes, putting more strain on standby current. In addition, with smaller process nodes (45nm and 28nm) the power density increases, causing the need for more power and voltage domains on chip (that need to be controlled) in order to lower the average power of the SoC. So, how can we get ahead of this power curve (no pun intended) and get back to one-week standby times?

To truly create power-aware designs it will take a combination of system-architecture design, EDA tools, software and IP. Part of the challenge is that there is typically no one person on the design team responsible for power. Each piece of the system is doing its best to conserve power, but this, if not viewed from the system level, can hurt power consumption because what appears to be saving power in one domain is actually increasing the power in another. (I presented a paper demonstrating this effect at CDNLive! in San Jose last year). The other issue is that power management is often seen as the job of the operating system, which depending on the OS, has limited visibility and control of the low-level hardware, thereby creating inefficiencies in power control.

Some help has come from EDA tools using CPF and UPF, which allow the power intent to be specified at the architectural level and then translated down to various IP blocks that are compatible with these power formants. Running a power compiler also helps by reducing leakage current. Although helpful, these techniques need to be coupled with more aggressive forms of power management at the system and architecture level to meet the overall system power requirement.

Ideally, adding a system level power manager IP block will allow access to the lowest level of hardware, and at the same time, be able to communicate with the OS. This IP block will add a level of abstraction for the software, but not sacrifice fast and efficient power domain control. The power manager, when combined with an on-chip-network IP block, will have visibility into every core in the system along with visibility into all the traffic flow. These two combined resources will enable much faster and more reliable wake-up and shut-down of domains since these events will be based on actual traffic (or lack thereof) in each core. Data integrity is also maintained because now systematic shutdown can occur—no data lost!

These kinds of architectural changes are clearly needed for the silicon portion of the phone (at least) to do its part to keep my charger in my laptop bag and not constantly plugged into the wall.

–Frank Ferro is director of marketing at Sonics.