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

CIRCUIT

32-bit input 32-bit input

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

Simulation: spot coverage of design space

Motivation for Formal Verification

Formal Verification (ideal case): full coverage of design space

Simulation: spot coverage of design space

Motivation for Formal Verification

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

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!

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

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

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 1Axiom 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 | 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: McMillan, 1992 Innovation: Use Binary Decision

Diagrams (BDDs)• Found bug in published Encore Gigamax

protocol

(picture by “iMeowBot” at Wikipedia)

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

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

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

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

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

RTL

Netlists

Layout/Backend

FPV

FEV

CDC, TOV

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/lect1.pdf http://www.easychair.org/FLoC-06/kurshan_25mc_floc

06.pdf