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

Memocode 2009 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

Memocode 2009 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!

Memocode 2009 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 Scheme Verification Goals DPM verification is important!

Memocode 2009 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 Add difficult-to-verify DPM - Increased time to market - Coverage goals not reached - Missed bugs - Disable DPM scheme? ?

Memocode 2009 Acceptable Power/Performance? Early in Design Current DPM Design and Verification DPM Scheme Concept Detailed Simulation Found Bug? Sufficient Coverage? Done Yes No Late in Design High-Level Model No 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

Memocode 2009 Acceptable Power/Performance? Early in Design Proposed DPM Design and Verification DPM Scheme Concept Detailed Simulation Found Bug? Sufficient Coverage? Done Yes No Late in Design High-Level Model No Successful Verification? Verification Scalability? High-Level Formal Model Yes 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

Memocode 2009 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 Research Contributions DPM Parameter Performance Verification Effort X X

Memocode 2009 Outline Motivation & Proposed Approach Illustrative DPM Verification Examples Experiments and Results Conclusion

Memocode 2009 FreqV DD IPC Core 1 Global Controller Power Budget Monitor Power Use Actuate V DD, Frequency FreqV DD IPC Core 2 FreqV DD IPC Core 3 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 V DD

Memocode 2009 * Global Power Use Budget Max Power Time Actuate V DD Actuate Frequency * * * Considered DPM Scheme Global controller –Monitor power usage –Actuate V DD and Frequency of cores to cap power Actuate V DD and Frequency every 500us Actuate only Frequency every 100us FrequencyV DD IPC Core 1 Global Controller Power Budget Monitor Power Use Actuate V DD, Frequency FrequencyV DD IPC Core 2 FrequencyV DD IPC Core 3

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

Memocode 2009 DPM Verification with PRISM Model Checker Correct? YES NO Done Model Checker State Variables Transition Rules Correctness Properties Model Description –State variables Current V DD, 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

Memocode 2009 DPM Verification with PRISM Model Checker Correct? YES NO Done Model Checker State Variables Transition Rules Correctness Properties Correctness Properties –For every reachable state V DD 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

Memocode 2009 Outline Motivation & Proposed Approach Illustrative DPM Verification Examples Experiments and Results Conclusion

Memocode 2009 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

Memocode 2009 Results: Voltage Levels

Memocode 2009 Results: Freq. Levels per Voltage Level

Memocode 2009 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

Memocode 2009 Thank You!