Why Does That App Make My Phone Hot?

By Adam Sherer
Popular Mechanics examined this topic in 2011, focusing mostly on packaging and other physical conditions. “Poor signal, intense workload and battery charging” were quoted, but the verification engineer knows the part of that list that was glossed over—intense workload. The author of that article waved away that aspect, saying the operating system usually can handle the software issues and the user just needs to live with the other two. Yikes! If I’m building a smartphone I surely need to worry about all three because I know my competitors are. But because I’m a verification engineer, I’ll worry most about this mysterious “intense workload.”

To solve this mystery we need to start by looking at the SoC verification process itself. Greatly simplified, the process starts with a foundation of confidence in each individual block of IP, moving on to subsystems, and then building to the full SoC including software. It must be layered because the complexity of the SoC demands a distributed development team that almost always includes third-party developers. While the layers provide critical operational flexibility, they also can be the source for the mysterious power consumption.

The IP layer is characterized by rigorous verification. For blocks with power control, this typically means a comprehensive set of directed tests that verify every mode in which the IP can operate. Ideally, the IP developer will include assertions automatically generated from the power format to alert the subsystem verification engineer when the block is operating in an illegal mode.

Multiple power domains often come into play at the subsystem level. The verification engineer will inherit the directed tests from each IP component but needs to reconfigure those to the actual set of power modes specified for the subsystem. Depending upon the specification, the subsystem may or may not use all of the modes available in a given IP block. Randomization is useful at this layer to verify that the subsystem operates in legal modes and doesn’t operate in illegal ones. As the number of power domains grows, so does the risk that improper mode switching can cause mysterious power spikes. Verification engineers should move to a randomization-driven methodology using the Accellera Universal Verification Methodology (UVM) when the number of illegal modes is more than 3x the number of legal modes due to the complexity of building and maintaining directed tests.

The foundation work at the IP and subsystem level is critical because the real-world power configurations are defined at the SoC layer in the context of software. At this point, developers with no knowledge of the underlying silicon write their Apps. The software API describes how to access each function of the SoC, and that API assumes that the silicon will defend against poor power configurations. This is where mysterious “intense workload” is most likely to occur in the field. To prevent that, system verification engineers should use hardware-based acceleration systems to measure peak power while running real software apps. It’s far better to see the power spike in a waveform than feel it heat up in your hand.

As a happy smartphone owner I’ve come to know which of my Apps is a power hog. While I expect the streaming radio app to pull a lot of power, I’m often surprised by the simple games that do the same. Why does that App make my phone hot? The answer is probably hidden in the layers of verification for the complex, power-managed SoC.

—Adam Sherer is verification product management director at Cadence.