Formal Verification: An Overview

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 32-bit input 32-bit input CIRCUIT 232 * 232 = 264 possible input sets  If super-fast simulator runs 232 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. Motivation for Formal Verification Simulation: spot coverage of design space

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

11. Motivation for Formal Verification Formal Verification (real life): full coverage in some areas Formal Verification (ideal case): full coverage of design space Simulation: spot coverage of design space

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

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 FPV Architecture CDC, TOV RTL Netlists FEV Layout/Backend

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, erik@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 • 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 • 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_floc06.pdf