Using Formal Verification to Replace Mainstream Simulation

1. Using Formal Verification to Replace Mainstream Simulation

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

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.

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

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

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

7. Why More Formal Verification (FV)? • 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 Full Chip Simulation Cluster1 ClusterN Cluster Level Simulation- Gone? EXE … Formal Verification– by FV Experts 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

10. Pioneering Challenges & Solutions

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

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 can’t 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 don’t want to redo effort

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

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