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
?
Memocode 2009
Acceptable Power/Performance?
Early inDesign
Current DPM Design and Verification DPM Scheme Concept
Detailed Simulation
Found Bug?
Sufficient Coverage?
Done
Yes
Yes
No
No
Late inDesign
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 inDesign
Proposed DPM Design and Verification DPM Scheme Concept
Detailed Simulation
Found Bug?
Sufficient Coverage?
Done
Yes
Yes
No
No
Late inDesign
High-Level Model
No
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
FreqVDD
IPC
Core 1
Global Controller
Power Budget
Monitor Power Use
Actuate VDD, Frequency
FreqVDD
IPC
Core 2
FreqVDD
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
VDD VDD
Memocode 2009
*
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Global Power
UseBudget
Max Power
Time
Actuate VDD Actuate Frequency
**
*
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
FrequencyVDD
IPCCore 1
Global Controller
Power Budget
Monitor Power Use
Actuate VDD, Frequency
FrequencyVDD
IPCCore 2
FrequencyVDD
IPCCore 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?
BudgetController Actuator System
Utilization (IPC)
+
Approximate Power Usage
f(IPC, VDD, Freq)
• 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 2 Cores per controller 3 Cores per controller
Memocode 2009
DPM Verification with PRISM Model Checker
Correct? YES
NO
Done
Model Checker
State Variable
s
Transition Rules
Correctness
Properties
0.4
0.2
0.30.1
0.6
0.40.2
0.40.4
1
• 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
Memocode 2009
DPM Verification with PRISM Model Checker
Correct? YES
NO
Done
Model Checker
State Variable
s
Transition Rules
Correctness
Properties
0.4
0.2
0.30.1
0.6
0.40.2
0.40.4
1
• 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
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!
