formal verification: an overview erik seligman cs 510, lecture 1, january 2009
TRANSCRIPT
Formal Verification: An Overview
Erik Seligman
CS 510, Lecture 1, January 2009
Introductions (people)
Stand up & introduce yourself!
Who Am I?
Erik Seligman M.S. Computer Science, Carnegie Mellon
• No Ph.D.– I live in the Real World
14 years at Intel• Positions including design, simulation software,
validation, and formal verification
• Currently Formal Verification Architect in “Corporate Design Solutions”
• Support formal use on Intel projects worldwide
Introduction to Formal Verification
Memories of FDIV
June 1994: Oops!
(4195835*3145727)/3145727 = 4195579 October: Error posted in public, mass panic
December: Recall! Intel agrees to replace any Pentiums with the bug• $$$$$$$$
What was the problem?
• Graph from Larry Hoyle, U. Kansas: x, y, x/y in small region
• In tiny portions of design space, wrong answers possible
Exhaustive Testing Not Possible
CIRCUIT
32-bit input 32-bit input
232 * 232 = 264 possible input sets
If super-fast simulator runs 232 cycles/sec, this circuit will take over 100 years to check
What is Formal Verification (FV)? Traditional validation= simulation vectors
• Choose wisely, measure coverage
• But still depend on selection of cases
Formal Verification = *Prove* correctness• Prove mathematically, for all testcases
Simulation: spot coverage of design space
Motivation for Formal Verification
Formal Verification (ideal case): full coverage of design space
Simulation: spot coverage of design space
Motivation for Formal Verification
Formal Verification (ideal case): full coverage of design space
Simulation: spot coverage of design space
Motivation for Formal Verification
Formal Verification (real life): full coverage in some areas
The Validation Crisis
Chips getting more complex Good, targeted testing is mature
• BUT most of design space not tested
Can formal verification help fill the gap?• Technologies esoteric at first (PhDs only)
• BUT many FV areas now viable for “normal” engineers
• Complements, doesn’t replace, simulation
Understand and use FV when applicable!
Types of Formal Verification
Formal Equivalence Verification (FEV)
Best-established form of FV Answers question: Are two models equivalent?
Main usage: RTL vs schematics (netlist)
• Did synthesis do the right thing?
• Does hand-drawn circuit match intent? Also useful for checking safety of changes
Assertion Based Verification (ABV) Adding properties to design
A1: assert property ($onehot0({a,b,c}));
Properties used in simulation or FV• So ABV not strictly a formal method
Usually discussed within FV topic• FV is strongest motivation for ABV
• Precise description– formal in some sense
• But very useful with simulation too
Formal Property Verification (FPV) Does design obey its properties?
ASSERT MUTEX (a,b,c)
Many teams use ABV but afraid of FPV
Clock Domain Crossing (CDC) Are crossings between clock regions
handled safely?
10 GHz 5 GHz
Borderline between linting & FV• Many errors caught with simple examination
Timing Override Verification (TOV) Are false and multicycle paths consistent
with logic?
Set_multicycle_path 2 –from a –to b
assert property ($changed(a) |=> $stable(a))
Other FV Not In This Class
High-level modeling FV• Build abstract spec above RTL level
• Reason about abstract properties
• May use model checking or general theorem proving
Symbolic trajectory evaluation (STE)• Simulate using symbols instead of values
• Very useful in datapath/arithmetic blocks
• No successful commercial tools
Formal Methods & Software
Active research area• Also beyond scope of this class
Some highlights• High-level specification: ‘synthesize’
software like hardware
• Functional programming: provably correct-by-construction software
• Proof-carrying code: construct security proofs as software is written
• Software formal property verification
History of Formal Verification
Automated Reasoning: A Dream
Axiom 1Axiom 2
Axiom 3
THEOREMS
Logic Theorist (1957)
Simple propositional logic prover, based on Principia Mathematica• Newell, Simon, Shaw
• Heuristic search of possible deductions for pairs of axioms
Proved 38 of 52 theorems in Ch.2• One claimed “more elegant” than original
BUT- very restricted, elementary portion of mathematical domain• Principia based on pure symbols
Sample Principia Page
Resolution Theorem Proving (Robinson, 1965) Simple automated reasoning algorithm
(oversimplified a bit for this slide)• List all clauses: {a | c, b | c, b | ~a}
• Find pairs to “resolve”:{a | c} & {b | ~a} {b | c}
• If you hit contradiction, disproved original set Many later refinements
• But few notable applications
• Most successful research == domain-specific problem solving
Model Checking: Clarke & Emerson, 1981 Focus: finite state machines & transitions
• Rather than general theorem-proving
Based on Temporal Logics• Linear Temporal Logic: Boolean + always,
until, eventually, etc.
• Computation Tree Logic: add “for all futures” & “for some futures”
Restrictions ideally suited to hardware verification
Practical Model Checking: McMillan, 1992 Innovation: Use Binary Decision
Diagrams (BDDs)• Found bug in published Encore Gigamax
protocol
(picture by “iMeowBot” at Wikipedia)
FV Explosion in 1990s-2000s
Homemade FV at Intel, IBM, DEC… Late 90s: Commercial tools enter the mix
• 1996: 0in founded (Formal Property Verification & Clock Domain Crossing tools, eventually purchased by Mentor)
• 1997: Verplex founded (Formal Equivalence Verification tool became Cadence Conformal)
Now major EDA companies (Synopsys, Mentor, Cadence) all have FV offerings• Plus numerous startups: Jasper, OneSpin, Averant,
RealIntent, Fishtail, Avery
2003+: Standardizing Assertions OVL: Open Verification Library
• Used existing languages
• ‘printf’, etc., to flag failures
PSL, SVA: True assertion languages• Constructs for building temporal logic
• Could be embedded in Verilog, VHDL, etc.– SVA = “System Verilog Assertions” though
SVA+• New 2009 standard based on real-life experience
with earlier standards
• Part of new 2009 IEEE p1800 SV revision
Challenges of Formal Verification
High-Level Objection #1: Godel Godel’s incompleteness theorem
• For a sufficiently complex formal system, there will always be some true statements that are not provable
• Works by building statement “This statement cannot be formally proven.”
There will be some problems not solvable thru FV.
High-Level Objection #2: The Halting Problem Decidability: Can a computer be
designed to always tell if another one halts?• No! Proof (Turing, 1936): Create a
complement computer, and apply to itself…
There will always be failures of formal analysis.
High-Level Objection #3: NP-Completeness An NP-Complete problem can probably*
not be solved by any polynomial-time algorithm• * unless P=NP, and all of them can be
First NP-complete problem: SAT= Can a boolean equation be satisfied?
• Sounds a lot like design verification…
No FV algorithm will be able to solve all problems in polynomial time
But FV *is* Real!
Previous slides prove bad cases exist• But true of many areas of software
Real question: good heuristics?• Can common problems be solved?
• Can we know when to try harder vs give up?
Only answers are through experience Industry has shown that FV *is* practical
• Though never guaranteed
Complexity of FV?
Exponential in worst case But complexity not directly proportional
to model size• Contrast with simulation
• Small pathological model may be infeasible
• Large well-behaved model may be OK Need variety of techniques to manage
complexity• This is just overview, details will be in future
weeks!
Simplification #1: State-Matching for FEV Break up designs at latches & flopsFEV can eliminate temporal issues
• Cost: Schematics must state-match RTL• Except in certain special cases for latest tools
• Works very well in practice• FEV = requirement in good design teams
• But there are often complexity cases
Simplification #2: Reduce Size/Scope Run at lower hierarchies
• Block or sub-block, not full chip like simulation
Restrict inputs• Only examine for special cases
Abstract complex logic• Do you need full general arithmetic sub-block, or just
something that generates numbers?
• How many bits of memory are really needed for essential properties?
Explicit Pruning• Chop away parts of logic you won’t need for proof
Simplification #3: Bounded Proofs What really needs proving?
• S is always true, or
• S is true in all simulations up to bound <n>
First statement is best• But second may be much less expensive
• Perhaps for some <n>, second statement is almost as good for your model
Simplification #4: Domain-Specific FV Pre-analyze common structures
• Clock-gating violates state match for FEV…
• But well-understood structures OK
Focus on domain-specific problems• Clock Domain Crossing (CDC)
• Timing Override Verificaion (TOV)
Target efforts at areas with highest ROI!
FV And The Design Engineer
Review: Design Process
Architecture
RTL
Netlists
Layout/Backend
FV In The Design Process
Architecture
RTL
Netlists
Layout/Backend
FPV
FEV
CDC, TOV
Who Does Formal Verification? General DEs
• FEV for RTL-netlist closure– Often run high-level flows, little understanding– Experts needed for nontrivial cases
• Other areas optional– FPV, CDC, TOV mostly left to specialists
FV Specialists• Run most forms of FV
• But tools / methods have improved greatly– My contention: many DEs could gain from use!
FV Engineering Tasks (Classic Tom Schubert slide)
FV Challenge: Methodology
Where to fit in to design process?• Is FV a ‘bonus’ or part of the flow?
• In real life, “not required” == “never done”
Simulation is well-understood• Most designers simulating for decades
– FV is new concept: “why bother?”
• Momentum: strict simulation requirements– Measurement well-understood– Always match #cycles, coverage in last project
Need to understand: FV is a powerful complementary method• Often finds issues missed completely in simulation
Class Logistics
Who Am I?
Erik Seligman, [email protected]• Twitter (if you use it): erikseligman
Cell 503-312-1665 “Office” hours: 1 hr before class, I’ll hang
around the classroom • Other times by appointment
• Emergency contact: Fei Xie
Class Web Page: www.cecs.pdx.edu/~eseligma• Watch for updates!
Assignments
Each Monday, will hand out problem set or verification assignment
Hand in hardcopy the following Monday• Print out log if CAD tool used
• -20 pts per day late
• Assignments= 70% of grade, take-home final= 30%
Alternate assignment proposals are fine• Can work on real design instead of my toy cases
• BUT avoid commercial designs (CAD vendors loaned educational licenses)
Some References
http://www.cs.rice.edu/~vardi/logic/km.ppt http://www.cs.utt.ro/~marius/curs/vf/old/lect1.pdf http://www.easychair.org/FLoC-06/kurshan_25mc_floc
06.pdf