IPSoC: Software power optimization ‘must start earlier’
Embedded software engineers need to focus on power optimization in their code much earlier and more comprehensively than many of them do today, Mentor Graphics technologist Colin Walls told delegates at the IPSoC conference in Grenoble, France today.
“The problem is that power optimization is being done late. You need to consider power from day one. Meeting power requirements should be part of code functionality,” said Walls. “You have to choose goals, and goals that are measurable. And you need to consider them all the way through the development cycle.
“Power should be measured from day one,” Walls stressed. “All software engineers should be equipped to measure power.
You might say they don’t have the hardware target to use until quite late in the project. But there are plenty of simulation environments around that will give them an idea.”
Walls described the process of defining and adhering to power-consumption goals in the form of a pyramid that has hardware at its base, on top of which are the typical use-cases for the system; the operating system; drivers; and finally applications.
Although application writers cannot do nearly as much to affect power consumption as those dealing with low-level behaviour and drivers, Walls said badly written applications code can easily
For software engineers, the most important consideration lies in the use-cases. Defining and modelling those provides the key to whether the end product stands a chance of running for a reasonable time on a single charge.
“You need to look at how much functionality each use-case needs and which drivers and hardware need to be active,” said Walls. “Then figure out what the battery lifetime will be as a result of that analysis.”
As the energy usage of a given function will the product of its active consumption and frequency of use, software engineers can make big savings by finding ways to ensure that major consumers do not execute too frequently.
A more subtle tradeoff lies in the use of suspend and hibernation modes. The latter generally means transferring data into flash or similar non-volatile storage, while suspend uses more power but retains the contents of memory and registers.
“The cost of entering and exiting these modes has to be considered. There is a power cost. You have to execute code to get into a state where you can store and recover data. There is also a time factor. If device responds too slowly, the user will tend to leave it switched on,” Walls explained.
Over-ambitious power control can lead to other problems, Walls said: “Consider what happens if a driver starts off a DMA transfer and the CPU immediately decides to have a siesta. Reducing the frequency could slow the DMA down and mess up the transfer. So the driver needs to notify the CPU that it has started a DMA so that the operating system or power management software doesn’t turn the frequency down or put system to sleep. If this isn’t spotted, it can lead to some very subtle bugs.”
For many teams there is a more immediate problem, Walls said: “The really hard thing is to get the guys to care. The biggest challenge is social not technical.”
