High Level Power Modeling

Transcription

1 High Level Power Modeling Jerry Frenkil (Sequence Design) David Hathaway (IBM) Nagu Dhanwada (IBM) Si2 LPC Modeling Working Group Interoperability Standards Collaborative Technology Innovation Through Collaboration

2 Topics Some perspectives Requirements A proposal An example Future work Summary

3 Generalized Low-Power Design Flow Design Phase System-Level Design RTL Design Implementation [Ref: Frenkil & Rabaey, Low Power Design Essentials] Low Power Design Activities Explore architectures and algorithms for power efficiency Map functions to sw and/or hw blocks for power efficiency Choose voltages and frequencies Evaluate power consumption for different operational modes Generate budgets for power, performance, area Generate RTL to match system-level model Select IP blocks Analyze and optimize power at module level and chip level Analyze power implications of test features Check power against budget for various modes Synthesize RTL to gates using power optimizations Floorplan, place and route design Optimize dynamic and leakage power Verify power budgets and power delivery

4 Three Inter-related Perspectives Characterization the generation of raw (unstructured) power data to be used in creating a higher-level view of the logic s power characteristics Modeling the fitting of the of the characterization data into a structure for use by an application operating at a higher level of abstraction than the level at which the data was characterized Evaluation the usage of the model data with regards to a particular stimulus by an application (such as a power simulator)

5 A Few Modeling Issues Characterization: raw data generation Which data is generated? modes, power types (dynamic, leakage), sensitivities (PVT) How much data is generated? how many modes & sensitivities, functional coverage How is the data generated? simulation or derivation, transistor or gate level netlist When is the data generated? at library generation time or at library usage time Modeling: converting the raw data into a usable form What is the model structure? parameterized or not, full detailed or transactional, functional coverage What is the modeling language? Liberty, XML, or something else What type of analysis is to be supported? P avg or P(t) What type of application will use these models? Voltage drop, thermal analysis, avg pwr? What is the desired level of accuracy? What are the power dependencies / optimization dimensions needed? Evaluation: use of the models by an application Which tools will consume these models? What type of reports are desired? What is the desired level of accuracy? Characterization, Modeling, and Usage are all interdependent Solutions for one issue typically impact other issues

6 High Level Modeling Requirements 1 Each of the three perspectives (characterization, modeling, evaluation) poses particular requirements Characterization Requirements The characterized data must be generated automatically in a reasonable amount of time If characterization takes too long it will not be practical The characterized data must be complete All possible power consuming conditions or events must be represented The characterized data must be generated in such a way that the model can be created automatically If the model cannot be constructed automatically it is less likely to be built

7 High Level Modeling Requirements 2 Modeling requirements the models must support Non-mutual-exclusivity amongst power conditions to avoid exponential state explosion Ex: two or more incomplete state expressions could match for a given simulation condition Abstract events or transactions so as to be useable with TLM simulations Ex: power specifications for multi-cycle operations such as a burst transfer Both atomic and non-atomic (composite) construction for modeling flexibility and transportability across libraries and/or processes Ex: a model for a burst transfer can reference lower level models that represent each individual cycle in the multi-cycle transfer Evaluation at multiple levels / mixed modes Ex: a model should be usable for multiple levels of power analysis i.e., it should not be limited to only gate-level analysis or RTL analysis or TLM analysis Categorization Ex: a model must be able to separately represent dynamic power, static power, and leakage power.

8 High Level Modeling Requirements 3 Modeling requirements continued the models must support Different measurement types (levels of temporal resolution) 1. Waveform for a simple event: resolution < clk cycle Similar to existing capabilities in ccs or ecsm today 2. Waveform for a complex (multi-cycle) event: resolution = clk cycle No standard representation available today 3. Total energy for complex (multi-cycle) event Similar to existing (table based) capabilities in Liberty today, except that Liberty cannot represent complex events Evaluation Requirements The model must be capable of evaluation in a reasonable amount of time

9 Modeling Proposal Conceptual Overview Non-mutex states not allowed in Liberty Cond. 1a Cond. 1b Cond. 2a Cond. 2b else Guard conditions in mutex groups F1(bus1_switch, bus2_value) F2(bus1_switch, bus3_num_ones) FN( ) Contributor functions (functions of activity parms, optionally PVT, tagged by category) Not included in Liberty Switching cap Crossover-current Channel leakage (per FET type, Leff) Gate leakage (per FET type, Leff) Resistive power (e.g., terminators) Contributor eval. (function of PVT, maybe slew, load) Numbers Energy, Power

10 General Idea of Multi-Level Power Modeling Have expressions / conditions at each level Guard conditions can be grouped Guard conditions can be mutex or non-mutex Contributor functions can be workload based or structure based Objects at one level can call out one or more objects at the next level Can include scaling Cond. 1a Cond. 1b Cond. 2a Cond. 2b else Guard Conditions F1(bus1_switch, bus2_value) F2(bus1_switch, bus3_num_ones) Contributor Functions Tools can take advantage of levels Find total weight for all conditions at one level, from all at previous level Facilitates abstract generation FN( ) Switching cap Crossover-current Channel leakage (per FET type, Leff) Gate leakage (per FET type, Leff) Resistive power (e.g., terminators) Contributor Evaluation Energy, Power

11 Example: Transaction Execution in a TLM Sim ISS + SystemC Wrapper ICU plb_mp1 DCU plb_mp2 #define Ext_Mem 0x6F00 main (..) { char *p = Ext_Mem; // ; *p = A + B; //.; } Arbiter plb_arbiter_if plb_ap Primary Bus plb_sp1 Pri_Sec Bridge opb_mp1 Sec Bus opb_sp1 Memory Controller mem_p Address map: 0x6000 to 0x6FFF Memory Model 1) Issw.plb_mp2->non_blocking_write (0x6F00, sum(a+b)) 2) plb_bus.plb_ap->arbitrate_request( ) 3) Plb queries its slaves and finds plb_opb_bridge mapped to address 0x6F00 4) plb_bus.plb_sp1->write(0x6f00, sum) [PLB Write] 5) brg.opb_mp1->non_blocking_write (0x6F00, sum) 6) opb_bus.opb_sp1->write(0x6f00, sum) [OPB Write] 7) mc.mem_p->write(0x6f00, sum) 8) Mem[0x6F00] = sum

12 Sample Power Profile for the TLM Sim Example Power ISS + SystemC Wrapper ICU plb_mp1 DCU plb_mp2 #define Ext_Mem 0x6F00 main (..) { char *p = Ext_Mem; // ; *p = A + B; //.; } Arbiter plb_arbiter_if plb_ap Primary Bus plb_sp1 Pri_Sec Bridge opb_mp1 Sec Bus opb_sp1 Memory Controller mem_p Address map: 0x6000 to 0x6FFF #define Ext_Mem 0x6F00 main (..) { char *p = Ext_Mem; // ; *p = A + B; //.; } Memory Model 1) Issw.plb_mp2->non_blocking_write (0x6F00, sum(a+b)) 2) plb_bus.plb_ap->arbitrate_request( ) 3) Plb queries its slaves and finds plb_opb_bridge mapped to address 0x6F00 4) plb_bus.plb_sp1->write(0x6f00, sum) [PLB Write] 5) brg.opb_mp1->non_blocking_write (0x6F00, sum) 6) opb_bus.opb_sp1->write(0x6f00, sum) [OPB Write] 7) mc.mem_p->write(0x6f00, sum) Time 8) Mem[0x6F00] = sum

13 Modeling Proposal: An Example PLB Mem- OPB Mem PLB Read PCI Mem-Mem Hierarchical Guard conditions ReadPower(PLB, BitWidth, BufferSize, DataSwitchRate) PLB Write WritePower(PLB, BitWidth, BufferSize, DataSwitchRate) OPB Write WritePower(OPB,Bi twidth, BufferSize, DataSwitchRate) FN( ) DynamicPower(Read, PLB, BitWidth, BufferSize, DataSwitchRate) SaticPower(Read, PLB, BitWidth, BufferSize, DataSwitchRate) DynamicPower(Write, PLB, BitWidth, BufferSize, DataSwitchRate) StaticPower(Write, PLB, BitWidth, BufferSize, DataSwitchRate) DynamicPower(Read, OPB, BitWidth, BufferSize, DataSwitchRate) StaticPower(Read, OPB, BitWidth, BufferSize, DataSwitchRate) Hierarchical Contributor functions (functions of activity parameters) Switching cap Crossover -current Channel leakage (per FET type, Leff) Gate leakage (per FET type, Leff) Resistive power (e.g., terminators) Contributor evaluation Numbers Energy, Power

14 Future Work Prepare a list of specific modeling features / extensions required to enable high level power modeling, including a proposed syntax Define how the new features would work with existing modeling capabilities so as to enable backwards compatibility Define the data types needed from simulation traces Describe how to build models based on this formalism Bottom up (for pre-existing functions) Top down (for new, yet to be designed functions) Illustrate the above with examples of varying complexity Prepare a requirements document containing all of the above

15 Summary The lack of structured high-level modeling capabilities hinders power analyses during early design phases We have begun to codify requirements and have prepared an outline for a multi-layer power modeling proposal, presented here The proposed structure should be applicable to a wide range of functional complexity as well as a variety of simulation styles Future work has been identified with the goal of preparing a formal requirements document

16 Acknowledgement The work presented here is a product of the LPC Modeling Working Group Nagu Dhanwada (IBM) Jerry Frenkil (Sequence Design) David Hathaway (IBM) Rachida Kebichi (AMD) Chair Andres Teene (LSI)

17 Appendix

18 Motivations Enable power tradeoffs during system level design & sim Enable earliest view of system power characteristics Power modeling capabilities exist for low level primitives (Liberty), but are not sufficient for high level modeling This is not intended to replace Liberty models, but to extend or complement them. Some power models exist for IP blocks, but Difficult to generate (characterize and model) Modeling constructs are inadequate for representing complex power behavior Models are often incomplete, inaccurate, or both Models are often non-transportable between applications This topic is very timely, since more formalism at the ESL level is developing, especially wrt TLM modeling

19 Power Characterization and Modeling V dd I sc I L I leakage [Ref: Frenkil & Rabaey, Low Power Design Essentials] C L Process Model Spice Netlists Library Params Power Characterization (using a circuit or power simulator) Characterization Database (raw power data) Power Modeler Power Models Model Templates

20 Model Evaluation (some background) mode 1 RTL mode 2 Stimulus RTL mode n Stimulus RTL Stimulus RTL Simulation mode 1 Activity mode 2 Data Activity mode n Data Activity Data [Ref: Frenkil & Rabaey, Low Power Design Essentials] RTL Design RTL Synthesis gate netlist Gate level power models Env. Data Gate level Power Analysis Power Reports Power Reports Power Reports Tech. Data