Software Driven Power Analysis

Power is a fundamentally hard problem. When you have finished the design, you have accurate power numbers but can’t do anything about them. At the RTL level you have some power information but it is often too late to make major architectural changes (add an offload audio-processor, for example). Early in the design, making changes is easy but you often lack accurate data to use to guide what changes make sense.

In many systems, power depends on what the SoC is doing and, in turn, that depends on the software. For example, a cell-phone obviously consumes different amounts of power when you are making a call from when it is just sitting in your pocket. In fact the power changes dramatically depending on whether you are talking (lots of data to transmit) versus listening (the transmitter, a huge power hog, is mostly idle). What the system is doing depends largely on what the software on the phone has enabled and disabled.

Assuming you have a virtual platform, and there are all sorts of reasons why you should that have been covered in earlier blogs, then you can use it to do power analysis. The reality in many SoC designs is that the power consumption depends on the contents of a comparatively small number of registers that enable or disable various functions, maybe disable their clocks, maybe power them down completely.

To do architectural power analysis proceeds in three steps. Firstly, identify the critical registers that alter the system behavior in ways that have a big impact on power. For example, going back to the cellphone there are probably registers that enable and disable the transmit and receive logic for the radio. If it is a multi-mode phone (GSM and CDMA) for sure there are registers that disable the logic associated with the unused standard. There may be registers that change the clock frequency of DSPs or control processors.

Second, having identified the registers, for each setting of the registers, the blocks concerned need to be analyzed for power using traditional EDA power analysis, probably at the RTL level unless more detailed information is available. The more “typical” the vectors you can get your hands on the better. Functional verification vectors are usually not very good for this since they are trying to exercise as many corner cases as possible, which, by definition, don’t happen very often.

So now you have a table of registers, and for each setting of those registers you have average power numbers. Next, instrument the virtual platform with callbacks. Each time the value of one of those registers changes then that needs to call back the virtual platform infrastructure and ultimately be logged along with the time or the clock-cycle.

Now you have a fully instrumented system. How do you exercise it? You run the software load. There are probably various software scenarios (boot, standby, listening to mp3, making a call, sending a text, surfing the net, using GPS and so on). You can run as many of these as is appropriate. You will end up with a logfile that shows when every register that has major effect on power changes. It is straightforward to work out what the average power for each block was and for how long, and then to add them up to get a total power number for that scenario. Obviously the total power for a system like a cellphone depends on what assumptions you make about how it is used. A teenager listening to mp3s all day and sending lots of text messages will have very different power consumption (aka battery life) from a salesman who practically lives on the phone making calls.

This doesn’t work for every SoC. In particular, if the power is very dependent on the data more than the mode the chip is in, then it is very important to have realistic data streams. Many SoCs are not like that though. A cellphone’s depends much more on whether you are speaking and hardly at all on what you say.

Download the Carbon whitepaper here.