Using Formal Verification to Replace
Mainstream Simulation
Erik Seligman
Brandon Smith
Intel
Intel
erik.seligman@intel.com
brandon.j.smith@intel.com
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
2
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
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
Outline
•
•
•
•
•
Current Validation Methodology
New Vision for Validation
Pioneering The New Vision
Example Validation Plan
Results and Future Plans
5
Current RTL Validation
Full Chip
Full Chip
Simulation
ClusterN
Cluster1
EXE
…
Cluster Level
Simulation
Formal
Verification– by
FV Experts
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
7
New Vision for Validation
Full Chip
Full Chip
Simulation
Cluster1
ClusterN
EXE
…
Cluster Level
SimulationGone?
Formal
Verification– by
FV Experts
Formal
Verification– by
anyone
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
Pioneering Challenges & Solutions
Challenge
Solution
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 don’t enable
simple assumptions.
Encourage reference modeling on
interfaces when applicable, +
reusable interface property sets
10
Sample Formal Verification Plan
Page Miss Handler
interface
Memory interface
= Reference Model
with Assumptions
Tracking FSM
interface
Backend Queue
interface
Instruction Fetch Unit
= Verification Focus
= Abstract/Reduce or Blackbox
11
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
12
Proposed POR: “FV Where We Can,
Simulate Where We Must”
Design
Exercise
Simulation
Formal
Eval FV results
Full Simulation
Sim + Formal
Full FV
13
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