Download presentation

Presentation is loading. Please wait.

Published byPaola Insley Modified over 2 years ago

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! ( * )/ = 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 “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

Similar presentations

© 2016 SlidePlayer.com Inc.

All rights reserved.

Ads by Google