Formal Verification An Overview Erik Seligman CS 510

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

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

Motivation for Formal Verification Simulation: spot coverage of design space

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

Motivation for Formal Verification Simulation: spot coverage of design space Formal Verification (ideal case): full coverage of design space 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 (Ph. Ds only) • BUT many FV areas now viable for “normal” engineers Complements, doesn’t replace, simulation • § Understand 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 A 1: assert property ($onehot 0({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 | ~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: Mc. Millan, 1992 § Innovation: Use Binary Decision Diagrams (BDDs) • Found bug in published Encore Gigamax protocol (picture by “i. Meow. Bot” at Wikipedia)

FV Explosion in 1990 s-2000 s § Homemade FV at Intel, IBM, DEC… § Late 90 s: Commercial tools enter the mix • 1996: 0 in 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, One. Spin, Averant, Real. Intent, 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 p 1800 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: NPCompleteness § 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 FPV CDC, TOV RTL Netlists FEV Layout/Backend

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

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. utt. ro/~marius/curs/vf/old/lect 1. pdf § http: //www. easychair. org/FLo. C 06/kurshan_25 mc_floc 06. pdf