1. Using Formal Verification to Replace Mainstream Simulation Erik Seligman Intel erik.seligman@intel.com Brandon Smith Intel brandon.j.smith@intel.com

2. For Submission: Author Slide Erik Seligman, Intel, 503-712-3134, erik.seligman@intel.com erik.seligman@intel.com Brandon Smith, Intel, 503-712-6294, brandon.j.smith@intel.com brandon.j.smith@intel.com 2

3. For Submission: Abstract Formal Verification (FV), the use of EDA software to mathematically prove that all possible behaviors of a Register Transfer Level (RTL) model will be correct, has been a successful and growing technique in design validation. While there is general agreement that FV is useful, it has most often been seen as an additional task to ensure extra safety, rather than a more efficient way to do mainstream validation of a design in progress. We believe that FV technology can now be used to replace a significant amount of the simulation that is currently done in our major core designs. There is clearly a need to improve our validation techniques, as our simulation environments have seemed to grow without bound, and now contain as much code, and as many bugs, as our actual RTL. Thus, the team decided to launch a pioneering effort to demonstrate that FV really could replace simulation as our main validation technique. In order to test this hypothesis, the team enlisted engineers on 11 major units of one of our core designs, and asked them to attempt to validate their units through formal verification. This group included engineers with little or no formal verification experience, as well as a few experts. As the team developed formal proofs on these units, they learned about the challenges of bringing FV to new units with inexperienced engineers, and report on our key takeaways from this effort. As a result of this pioneering, we are confident that FV can indeed be used as a primary validation strategy for applicable units on nearly any future Intel project. We conclude with a set of recommendations for managing the mix of formal and dynamic techniques during product development. 3

4. Acknowledgements This talk summarizes work by a large team, not just the authors! –M. Arifin, A. Bunker, V. Frolov, M. Lifshits, K. Natarajan, T. Schubert, F. Tabesh, A. Thatcher, C. Wall, R. Yan, C. Yan 4

5. Outline Current Validation Methodology New Vision for Validation Pioneering The New Vision Example Validation Plan Results and Future Plans 5

6. Current RTL Validation Full Chip Simulation Cluster Level Simulation Formal Verification– by FV Experts EXE ClusterN Cluster1 Full Chip …

7. Why More Formal Verification (FV)? 7 Early exercise independent of Test Env progress Instant Testbenches using coverpoint FV on new RTL Early block exercise before combining into unit Quickly find basic bugs Faster integrations by getting healthy RTL earlier Other Benefits of Formal Verification: Validate hard-to-hit conditions with relative ease Quicker and easier debug due to very short traces Instant validation of late-binding changes Complete validation sooner with excellent quality

8. New Vision for Validation Full Chip Simulation Cluster Level Simulation- Gone? Formal Verification– by FV Experts EXE ClusterN Cluster1 Full Chip Formal Verification– by anyone …

9. Pioneering the New Vision 11 core units chosen for pioneering –Varying levels of FV expertise among owners –3-month targeted effort (part time) Pioneering goals –Develop validation plans With path to simulation replacement –Build FV environment & wiggle models –Observe real traffic comparable with simulation tests 9

10. Pioneering Challenges & Solutions 10 ChallengeSolution Hard for non-experts to get started: general FV training overwhelming. Pair each non-expert with expert for initial bring-up. Local reset poorly understood.Use simulation reset initially. Experts help to understand. Conceptual change from active BFMs to passive assumptions. Emphasize interface assumes in FV plan. Also auto-generate simple constraints. Size of some units (300K+ flops) too large for formal. FV plan includes reducing structures & memories. Also need to improve RTL parameterization. Complex interfaces dont enable simple assumptions. Encourage reference modeling on interfaces when applicable, + reusable interface property sets

11. Sample Formal Verification Plan 11 Instruction Fetch Unit Page Miss Handler interface Memory interface Tracking FSM interface Backend Queue interface = Verification Focus = Abstract/Reduce or Blackbox = Reference Model with Assumptions

12. Results of Pioneering All 11 units are reasonable FV targets –Assuming expert help to get started –With proper abstraction & reduction –Best when full cluster can be built for FV FV very useful for design exercise –Wiggling waveforms in early/partial proofs –Enables quick sanity check in modified RTL FV assumption creation effort comparable to sim env development –But low ROI if good sim env already done BUT cant completely eliminate cluster simulation –Complex interfaces can be difficult to model passively –Some subset of non-fv-friendly unit types –Inherited units with lots of tests dont want to redo effort 12

13. Proposed POR: FV Where We Can, Simulate Where We Must 13 Simulation Formal Full Simulation Full FV Sim + Formal Design Exercise Eval FV results

14. Conclusions Formal Verification IS feasible for mainstream validators –But need experts to help with initial setup FV can replace lots of simulation –Some effort to bring up FV environment But current simulation envs effort-intensive & buggy –Not 100% of units, but major subset We should be doing more FV –Current efforts need to measure & report results –Focus on developing reusable FPV collateral –Demonstrate success to engineers and managers 14