Designing In The Dark

While power optimization has received significant focus recently, it is still largely a hidden cost to most hardware and software engineers. A significant problem is the lack of visibility into the impact of decisions while decisions are being made. Often an engineer working on a system will have no practical way of measuring the impact of their design decisions on the system power consumption. The first time accurate power information is available is often not until the system has gone through RTL implementation; at this point the amount of analysis that can be done is very limited so the bulk of power feedback is not available until the initial system prototypes are available.

This has led to two major areas of focus for power optimization. First, implementation optimizations (RTL through process) focus on the most efficient power implementation of a specific architecture. This level of optimizations can find a localized minimum, but are limited by the inability to make system-wide architectural tradeoffs and the inability to run real-world scenarios.

The second area is software optimization. Software designers can attempt to use the system in the most power efficient manner, but the software developers have a number of handicaps. As the hardware is fixed, they are locked into optimizing power with significant limitations on the kinds of changes that can be made. Also, they are now on the critical path. Because the prototype is already available, completing the software becomes the limiting factor to completing the system. Often software has been developed before the prototype is available or is being re-used from prior generations of a design. Going back and rewriting this software to optimize for power is generally not possible due to time constraints on completing the system integration.

Both of these power optimization approaches suffer from significant decoupling between the decisions that affect power consumption and the measurement of the power. Architectural decisions and software development often happen many months before implementation-based power measurement feedback is available.

The emerging answer is to invest more in power analysis at the system level, before architectural decisions have been locked into an implementation. By modeling power as part of a transaction-level model, we can provide quantitative feedback to design architects on the effect their decisions have on system power consumption. We can also use this model to provide feedback to software developers as to how efficiently they are using the hardware platform. The data from the software execution on the platform can be used to further refine the architectural choices made in the context of the actual software workloads.

Being able to optimize the system-level architecture with quantitative feedback tightly coupled to the workload (such as that shown in the figure below) allows us to measure the impact of our hardware and software decisions at the point where those decisions are made. Thus system-level power analysis exposes the effect of decisions on system wide power consumption, making them obvious and quantifiable to the hardware and software engineers.