# Formal Verification: An Overview Erik Seligman CS 510, Lecture 1, January 2009.

## Presentation on theme: "Formal Verification: An Overview Erik Seligman CS 510, Lecture 1, January 2009."— Presentation 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 2 32 * 2 32 = 2 64 possible input sets  If super-fast simulator runs 2 32 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 1 Axiom 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 & flops  FEV 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  First statement is best But second may be much less expensive Perhaps for some, 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, erik@erikseligman.comerik@erikseligman.com 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 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.rice.edu/~vardi/logic/km.ppt  http://www.cs.utt.ro/~marius/curs/vf/old/lect1.pdf http://www.cs.utt.ro/~marius/curs/vf/old/lect1.pdf  http://www.easychair.org/FLoC- 06/kurshan_25mc_floc06.pdf http://www.easychair.org/FLoC- 06/kurshan_25mc_floc06.pdf

Download ppt "Formal Verification: An Overview Erik Seligman CS 510, Lecture 1, January 2009."

Similar presentations