Power management was high on the feature lists of the products shown at July’s Design Automation Conference in San Francisco. For example, Mentor Graphics highlighted new features in its Vista platform that allow users to model, analyze, and optimize power at the transaction level of abstraction.
Now, developers can model power use with advanced power estimation policies before an implementation becomes available. These features also provide more accurate estimates of power behavior based on attributes of the target process technology.
New From Synopsys
Synopsys showed off its DesignWare minPower Components, which are intellectual-property products that are part of the Synopsys Eclypse Low Power Solution. They’re designed to provide major reductions in power for datapath logic compared to traditional power optimization methods.
With these design tools, developers can create hardware with improved power usage. In many cases, the hardware will deliver the desired performance with minimal software interaction. In others, software-based power management comes into play. Then, it’s up to the application or operating system to tune the hardware to provide optimal power usage.
Embedded developers working with microcontrollers are very familiar with the problem, but the application environments typically are simple enough, making control significantly easier. For example, these microcontrollers frequently have a range of low-power modes. Adjustments are often based on changes of frequency or power source. Sleep modes are typically characterized by how much power they require and how long it takes to wake up.
Things get a bit more interesting as designs incorporate technologies such as multicore and virtualization. Multicore provides one way to deliver more MIPS, but not all multicore designs are going to run all cores at full speed. In fact, for many embedded designs, the cores will need to be turned on and off or slowed and sped up to address power and performance requirements.
Virtualization simply lets more software run with applications another step away from power-management support. The problem is that power and performance considerations can change. Applications with hard-coded power management may be hard to alter. This approach also makes it hard to migrate an application to another platform.
Separating the power-management specifications from the implementation will make applications more flexible when it comes to power usage. One way to do this is to implement a policy-based system. I’m not talking about the simple power policies that PC users have in the control panel where timeouts specify when to shut down peripherals such as the hard disk or screen. I’m thinking of an implementation along the lines of the security in multilevel security (MLS) systems such as SELinux.
Secure Policies
Policy-based security frameworks permit mandatory access control policies to control what applications can utilize and what they can exchange with other applications. Applications can operate without concern for security, allowing the policies to set the stage or control security but only within the limits set by the policy.
Policy-based power management would need to be a little different than the security model because the policy is controlling how resources are used rather than what resources can be used. Still, the intent would be the same—separate the specification from the control.
Another difference is that a power-management hierarchy will sometimes need to flow through the task hierarchy because this dependency will usually be how the system will be related with respect to power usage. For example, an application may start up a set of tasks with a range of power requirements. The system will have to provide sufficient power to meet the needs of all of the active tasks.
Of course, the discussion is really about performance and power since they’re usually directly related. The policy approach I’m proposing really needs to specify performance as well as power requirements. Performance can be specified in a number of ways, from clock speed to scheduling priority to deadlines.
Building a policy-based performance and power system isn’t going to be an easy task, but the payoff will be a much more flexible system. It not only will entail an application programming interface and specification system, it also will need to address issues such as debugging, profiling, and even security.
Hardware will continue to provide more power-management capabilities. It will be up to developers to take advantage of them. So hopefully, the job will be a matter of working out a good performance and power policy and not just using a bigger battery.
Mentor Graphics
Synopsis