At DATEthis year in Dresden, Bernhard Fischer from Siemens CT(Corporate Technology) has presented an interesting summary of the various techniques used for power modeling and analysis at the architectural level. He went through the pros and cons of using spreadsheets, timed virtual platforms annotated with power numbers and a dedicated system level power modeling tool (Aceplorer). He also had an example application (a signal processing design) to show results mostly using the two latter approaches.
We mostly agree with the outcome of the study, and we encourage any person interested in power modeling at the architectural level to ask for a copy of the slides. I would like to add to the presentation a few points collected through my experience, working with Docea Power customers.
One general observation is that early power estimates are due way before any virtual platform is available. Most companies use a power model to answer Requests for Information (RFI) or Request for Quotations (RFQ) with statistical use case descriptions or dynamic representations of the most important use cases. Power architects are of course interested in the availability of a timed virtual platform as it provides a way to get a better use case representation, but they can’t wait till it is available, so they need to have a model of their own. Besides, power estimations need to take into account a complete device, not just the most important functional blocks, and this often includes analog and RF blocks and voltage regulators. Adding the different non-functional power consumers to the Virtual Platform further delays its delivery (which is mostly developed at the usage of system architects and software teams) and makes it more difficult to debug.
Another observation is that power architects expertise is not on functionality and SystemC coding and compiling, but rather on modeling the power behavior of blocks (leakage vs dynamic), on describing power management schemes, and on estimating the impact of different power reduction techniques. One core aspect we have found is to track power numbers (and indeed for a complex design there is a lot of data to manage), in order to be able to explore quickly any new configuration requested.
From a practical point of view, power architects have to perform a number of what-if analyses, to explore the best configuration on the number of power domains and voltage clustering. This is true for most complex designs today. To enable this exploration, power architects need an easy representation of supply rails and power domains definition. This is natively supported in Aceplorer as the tool is dedicated to power modeling. The methodology allows getting very accurate results as described in this paper from Jongho Kim (Samsung SLSI) presented at DAC 2013.
Our approach with regards to the link with virtual platforms is to get the best of both worlds! Virtual Platforms are an excellent way to describe the use cases. Whenever a virtual platform is available, with the right timing information and simulating meaningful use cases for the power architect, the activity of blocks can be monitored, captured in traces and used to describe use cases in Aceplorer. With this approach, the non-functional blocks are represented only in the power model, where they are needed and not in the virtual platform where they don’t add value.
The Aceplorer model is probably going to be pre-existing the virtual platform and a specific team in charge of its development and maintenance. The two models can be put in sync and we have demonstrated last year at DAC a mechanism to even have the virtual platform drive the Aceplorer simulation and get power and temperature feedback. This mechanism is ideal to develop and debug optimized power and thermal management policies and provide with more accurate leakage power numbers and better what-if analysis capabilities. This is in my humble opinion, how to get the best of both worlds…