Multicore Power Management:

1. Multicore Power Management: Ensuring Robustness via Early-Stage Formal Verification Anita Lungu*, Pradip Bose**, Daniel Sorin*, Steven German**, Geert Janssen** *Duke University **IBM T. J. Watson Research Center

2. High Level Motivation and Goal • Dynamic Power Management (DPM) is useful for multicore processors with power constraints • Goal: Enable DPM to be more easily adopted in current processors • Observation: A DPM that is easier to verify is more robust and more likely to be included in processors • Proposal: Design verification-aware DPM schemes

3. DPM for Multicore Processors We expect DPM to Increase power efficiency Avoid power spikes Cap power to allocated budget Etc. But, if incorrect, DPM can Throttle performance to unacceptable level Exceed allocated power budget Lead to data corruption Need to verify DPM schemes for correctness!

4. DPM Scheme Verification Goals • Safety: Power usage within desired levels & no deadlocks in DPM protocol • Bug: Power capping DPM often exceeds budget • Performance: resulting performance loss is acceptable • Functional Correctness: correct results with DPM • Bug: DPM increases dI/dt problem  data corruption DPM verification is important!

5. Importance of DPM Verification Effort • Design verification is challenging even without DPM! • ~60%of resources for new processor development allocated to verification • Important to consider DPM verification effort! • We approximate it as number of reachable states ?

6. Current DPM Design and Verification DPM Scheme Concept • Early design stage • Focus on DPM performance, power • DPM verifiability often not considered • Late design stage • Verify DPM scheme • DPM can have enormous reachable state space • Difficult to change DPM concept High-Level Model Early in Design No Acceptable Power/Performance? Found Bug? Detailed Simulation Yes Late in Design Sufficient Coverage? No No Yes Done

7. Proposed DPM Design and Verification DPM Scheme Concept • Validate high-level DPM concept through formal verification • Formal verification benefits: • Exhaustive traversal of reachable state space (of high-level model) • Estimation of size of reachable state space (verifiability) • Catch design bugs early High-Level Formal Model High-Level Model Early in Design Acceptable Power/Performance? Verification Scalability? No No Yes Successful Verification? Found Bug? Detailed Simulation Yes Late in Design Sufficient Coverage? No No Yes Done

8. Research Contributions • Use verifiability as additional metric considered at early DPM design stage • Compare verifiability of different DPM schemes • Evaluate trade-offs between verification effort, efficiency and safety of DPM schemes Verification Effort Performance X X DPM Parameter

9. Outline • Motivation & Proposed Approach • Illustrative DPM Verification Examples • Experiments and Results • Conclusion

10. Considered DPM Scheme • Goal: Maintain multiprocessor power usage below an allocated budget • Important problem for multicores • Increase in number of cores  increase in gap between average and peak power use Power Budget Global Controller Actuate VDD, Frequency Monitor Power Use VDD Freq VDD VDD Freq VDD Freq VDD IPC IPC IPC Core 1 Core 2 Core 3

11. Considered DPM Scheme • Global controller • Monitor power usage • Actuate VDD and Frequency of cores to cap power • Actuate VDD and Frequency every 500us • Actuate only Frequency every 100us Power Budget Global Controller Actuate VDD, Frequency Monitor Power Use VDD Frequency VDD Frequency VDD Frequency IPC IPC IPC Core 1 Core 2 Core 3 Actuate Frequency Global Power Use Actuate VDD * Max Power * * * Budget 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Time

12. DPM Parameters and Verifiability Utilization (IPC) • Controller algorithm: • Set next VDD and Frequency so power usage < budget • Design parameters: • Voltage levels, Frequency levels, Cores per controller • Homogeneous vs. heterogeneous VDD values Budget • Questions: • What is the impact on verifiability of above design decisions? • What are the tradeoffs between performance, verifiability and safety? + Controller Actuator System Approximate Power Usage f(IPC, VDD, Freq) 3 Cores per controller 2 Cores per controller

13. DPM Verification with PRISM Model Checker • Model Description • State variables • Current VDD, Frequency, Utilization values for all cores (~IPC) • Possible State: • One assignment of values to state variables from their domain • Reachable State: • One assignment of values to state variables allowed under DPM • Probabilistic transition rules • Probabilistic changes in utilization • State rewards • To each state, assign tokens representing power & performance State Variables Transition Rules Correctness Properties Model Checker 0.2 0.4 0.4 0.6 0.4 0.3 0.1 0.4 0.2 1 NO Correct? YES Done

14. DPM Verification with PRISM Model Checker • Correctness Properties • For every reachable state • VDD and Frequency values matched and within range • No deadlock • Along model execution paths • Power over budget < X% of total power • Performance loss < Y% of baseline • Model Check • Build model • Reachable states, expected values of rewards • Check correctness properties State Variables Transition Rules Correctness Properties Model Checker 0.2 0.4 0.4 0.6 0.4 0.3 0.1 0.4 0.2 1 NO Correct? YES Done

15. Outline • Motivation & Proposed Approach • Illustrative DPM Verification Examples • Experiments and Results • Conclusion

16. Methodology • Modeled 6 SPEC2000 benchmarks and their combinations • Art, bzip, crafty, eon, mcf, parser • Used probabilistic utilization transitions from simulation • Budget set to 25%, 40%, 50%, 70%, 100% of maximum • Trade-offs analysis • Verifiability metric • Number of reachable states and transitions • Performance metric • % Performance (Frequency) vs. baseline without DVFS • Safety metrics • % Power over budget of baseline system without DVFS • % Intervals over budget

17. Results: Voltage Levels

18. Results: Freq. Levels per Voltage Level

19. Conclusions • Making design choices with verification in mind does impact the resulting verification effort • Adding verifiability as a separate metric to be considered together with performance, reliability, and safety may lead to different design choices

20. Thank You!