Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "Formal Verification: An Overview Erik Seligman CS 510, Lecture 1, January 2009."— Presentation transcript:

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

2 Introductions (people)  Stand up & introduce yourself!

3 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

4 Introduction to Formal Verification

5 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 $$$$$$$$

6 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

7 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

8 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

9 Simulation: spot coverage of design space Motivation for Formal Verification

10 Formal Verification (ideal case): full coverage of design space Simulation: spot coverage of design space Motivation for Formal Verification

11 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

12 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!

13 Types of Formal Verification

14 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

15 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

16 Formal Property Verification (FPV)  Does design obey its properties? ASSERT MUTEX (a,b,c)  Many teams use ABV but afraid of FPV

17 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

18 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))

19 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

20 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

21 History of Formal Verification

22 Automated Reasoning: A Dream Axiom 1 Axiom 2 Axiom 3 THEOREMS

23 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

24 Sample Principia Page

25 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

26 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

27 Practical Model Checking: McMillan, 1992  Innovation: Use Binary Decision Diagrams (BDDs) Found bug in published Encore Gigamax protocol (picture by “iMeowBot” at Wikipedia)

28 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

29 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

30 Challenges of Formal Verification

31 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.

32 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.

33 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

34 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

35 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!

36 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

37 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

38 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

39 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!

40 FV And The Design Engineer

41 Review: Design Process Architecture RTL Netlists Layout/Backend

42 FV In The Design Process Architecture RTL Netlists Layout/Backend FPV FEV CDC, TOV

43 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!

44 FV Engineering Tasks (Classic Tom Schubert slide)

45 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

46 Class Logistics

47 Who Am I?  Erik Seligman, 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: Watch for updates!

48 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)

49 Some References    06/kurshan_25mc_floc06.pdf 06/kurshan_25mc_floc06.pdf

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

Similar presentations

Ads by Google