“Models should be as simple as possible… but no simpler!”. Albert Einstein’s philosophy captures an eternal truth in modeling the physical world for any given purpose. Why? Because unneeded detail takes more effort to create, more CPU run time to execute, while too little detail for the task means a non-competitive product. Modeling is complex topic all by itself (I will discuss the broader topic in an upcoming blog about the conundrum of modeling in general, and the role of standardization). As it turns out, power modeling is a particularly tricky special case.
Recently, fellow blogger and professional journalist Ed Sperling wisely observed that “power is creating a whole new layer of issues”. Even worse than that, power intersects with function, timing, area, reliability, packaging, battery life, etc. Modeling of power is fundamentally a flow issue as well as tools that must accommodate the appropriate design constraints,not just about a file format.
Allow me to share some excellent work the Low-Power Coalition (LPC) leadership has been doing to advance power-aware design capability in the modeling arena. The LPC has identified four areas of work, which I will explain below:
1. Implementation (cell) level: Liberty model enhancements for power;
2. Design level: complex atomic events in transaction-level (TLM) power models;
3. System level: structural definition for electronic system-level (ESL) power models; and
4. Layering “power variability” onto the design flow.
Large IP blocks have many internal states, often composed of subcomponents, each with their own power states. Requiring mutually-exclusive states, as Liberty specifies, can cause exponential state explosion. In one LPC example, an IP block containing 6 different memory arrays, each with 3 (sleep, nap, active) power states could be described with 18 power states (3*6). Coding this in Liberty, however, would require 729 power states! So the LPC has begun discussions with the Liberty TAB to offer Liberty enhancements for non-mutually-exclusive states to resolve this problem.
Today, it is nearly impossible to accurately model IP blocks and complex functions for power without modeling all internal transitions and lower-level data. The need is to atomically model power consumption of complex IP blocks purely at the transaction level. One proposed solution would be a Liberty enhancement to define state tables allowing assignments of energy to state transitions, however there are several workable approaches to deliver an interoperable capability here.
Most ESL tools do not directly address power modeling, and those that do lack any form of interoperability. The common practice of filling spreadsheets to manage power has reached its limits in terms of capacity, descriptive richness, and efficiency. So, the LPC is working toward defining an interoperable, machine-processable abstract structure for ESL-level power models. Questions to be addressed include: What data objects are needed? How are they inter-related? How would tools utilize this data? How much detail / accuracy is necessary, and how difficult is it to populate that data? Creating interoperable ESL-level power models could help the industry reach much-needed critical mass in this domain.
“Variation-aware” design has been a topic in several Si2 projects over the last 5 years, starting with the Open Modeling Coalition for timing, followed by the DFM Coalition for process parameters. Now, the same trends are emerging as important considerations for managing power, too. Today there are no standards for handling power variation – but this can be essential to balance between design failures due to missing corner case extremes as well as to avoid sacrificing performance, capability or cost due to unnecessary over-design. The impact of variations – caused by inter-related logical, electrical, and physical factors – is not constrained to a single point in the design flow.
In defining new standards, especially in emerging areas, how does an industry body assure a thorough result of enduring value and quality? The answer is to use a thorough process and engage key thought leaders across industry. LPC members outlined an approach for how to properly go about defining a power modeling standard the entire industry can use. For example, every feature might be accompanied by work flow use cases, and supported by a range of test case designs that include both a “top-down” power model (user-created) and a “bottoms-up” model (such as generated from characterization data). The design abstraction levels might include TLM, untimed, cycle-accurate, RTL, and so on. Required application features might include average, peak, static IR drop, EM analysis, transient power grid analysis, and so on. As you can tell, power modeling is indeed a complex topic, and it will surely be phased in and enhanced over a period of many years.
The first fruit of this process was the Power Modeling Requirements v1.0 specification, released in May, and v1.1 is being readied for a 2H10 release. Multiple very active working groups are discussing, aligning, and defining a path these companies intend to follow to achieve practical, adopted standards to benefit their corporate needs (as well as industry at large). In addition, invited guests include noted authorities from the academic and research communities.
I encourage anyone who sees value in these low-power modeling efforts to join the effort, to help us and themselves as well as the existing LPC members in achieving these ambitious goals. New participants are always welcome on a strictly non-discriminatory basis. You and your company can benefit from exchanging leading technology insights with the domain experts from the LPC member companies, and you can directly influence upcoming standards in the power modeling arena.