1 / 49

Formal Verification: An Overview

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

Patman
Download Presentation

Formal Verification: An Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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

More Related