Outbound Power Management

Many years ago when I first suggested that we should do platform-level power instead of focusing on the CPU, I was considered somewhat of a heretic. Yet, within 10 to 15 years of that recommendation, most of the platforms around us have moved to that method using operating system functions to keep track of the overall power, battery life, etc. As we move into the era of billions of connected devices, we are about to extend this paradigm one more time.

It is no surprise that in a tablet/smartphone or laptop, the screen, RF circuits and other peripherals such as disks take more power than the SoC itself. However, we focus a great deal of attention on SoC power analysis and optimization because of power density – the power consumed over a unit area. ICs have the highest power density on most platforms, and hence have to be brought into a safe operating temperature. On the other hand, the peripherals can be tuned at the platform level using software. However, this isn’t necessarily optimal for business. The development and validation time for platform-level power management often can run into months, delaying revenue realization.

The IoT era will add a further challenge to this problem. So far, we have had the “luxury” of having the entire platform physically co-located with and fed by the same power source. Neither assumption will be true in the IoT era. Similarly, we are accustomed to both digital and mixed-signal devices on the platform. We are now about to see an increasing number of electro-mechanical functions, especially in the medical and automotive markets. To put it more abstractly, we are about to take control of what we don’t necessarily have a solid model for. This will throw a rather large wrench into the world of software validation, verification and power/energy management.

A simple example is a mobile medical device that does blood tests. An embedded system with an RTOS controls electro-mechanical devices such as microfluidics pumps and micro needle actuators. Layered on top is a “classic” smartphone platform connecting these functions to a remote doctor. Software running on the SoC is the master for this platform. All the devices feed off the same battery power source. We are entering this brave new world of possibilities without any formal models for these complex devices. The SoC power consumption is miniscule compared to the power/current draw of these devices. In the coming years, we are about to see advances in modeling of such devices and integrated software control functions. The SoC will focus more on what it controls as power and not what it consumes at the platform level.

Stretching this example further, if we now put our SoC in-charge of a room or section in a hospital where it controls a range of medical devices/sensors connected to patients or monitoring the environment of the patient, the model gets even more interesting. The SoC will be operational for no specific “local” platform-level function, but to gain knowledge of remote devices, arbitrate among them, and make automated decisions that affect a set of systems elsewhere. This model of connected control comes with power management. We cannot leave tens of billions of devices in an always-on state. Hence, we will have to find ways to safely access/sense remote sets of devices, make decisions, and propagate them back to these devices or new ones.

In that sense, power management is going to take a 180-degree turn. For the last decade, we focused on managing inwards into the SoC. We will now spend the next decade making power management algorithms outbound.