Carnegie Mellon University Formal Verification of Infinite-State Systems Using Boolean Methods Formal Verification of Infinite-State Systems Using Boolean.

Carnegie Mellon University

Formal VerificationFormal Verificationof Infinite-State Systemsof Infinite-State SystemsUsing Boolean MethodsUsing Boolean Methods

Formal VerificationFormal Verificationof Infinite-State Systemsof Infinite-State SystemsUsing Boolean MethodsUsing Boolean Methods

http://www.cs.cmu.edu/~bryant

Randal E. Bryant

– 2 –FLoC ‘06

Main IdeasMain Ideas

Infinite State SystemsInfinite State Systems Greater power & generality than finite-state models Verified by extensions of finite-state model checking

Must find balance between expressiveness of model & ability to automate

OutlineOutline Why infinite state systems?

UCLID modeling capabilities

Verification methods Implementation

Advances in SAT and decision procedures

Prospects and challenges

– 3 –FLoC ‘06

Alpha 21264 Microprocessor

Microprocessor Report, Oct. 28, 1996

Verification ExampleVerification Example

TaskTask Verify that

microprocessor correctly implements instruction set definition

Even though heavily pipelined

– 4 –FLoC ‘06

Alpha 21264 Microprocessor

Microprocessor Report, Oct. 28, 1996

Verification ChallengesVerification Challenges

Sources of Sources of ComplexityComplexity Lots of internal state Complex control

logic

OpportunitiesOpportunities Most of the logic

serves to store, select, and communicate data

– 5 –FLoC ‘06

Sources of InfinitySources of Infinity

Real-life computers are finite state

Infinite-State AbstractionsInfinite-State Abstractions Traditional model for reasoning about programs

Soundness depends on properties being verified

Computer words Memory capacities

• • • ••• •••

tailtail headhead

In Use

– 6 –FLoC ‘06

Sources of Infinity (cont.) Sources of Infinity (cont.) Finite, but unbounded Synchronization protocol that should work for arbitrary

number of processes

Verify for arbitrary N

Circular buffer with fixed, but arbitrary capacity

Verify for arbitrary value of Max

••••••

tailtailheadhead

In Use

•••

0 0 Max-1Max-1

P 2 • • • P NP 1

– 7 –FLoC ‘06

Existing Automatic Verification MethodsExisting Automatic Verification Methods

Simulators, model checkers, …

All Operate at Bit LevelAll Operate at Bit Level State model

State encoded as words and arrays of wordsComprised of bits

Must track how each bit of state gets updated

Only Verify Single Instance of DesignOnly Verify Single Instance of Design Fixed values for parameters

Word sizeBuffer sizesNumber of processes

Some Work in Parameterized System VerificationSome Work in Parameterized System Verification Exploit symmetries in system Limited applicability

– 8 –FLoC ‘06

What About Theorem Provers?What About Theorem Provers?

Traditional Tool for Formal VerificationTraditional Tool for Formal Verification Allow many forms of abstraction

Hard to UseHard to Use Lots of manual effort & expertise required

Question:Question: Can we incorporate some of these abstraction abilities into

an automated tool?

– 9 –FLoC ‘06

UCLIDUCLID

Seshia, Lahiri, Bryant, CAV ‘02

Term-Level Verification SystemTerm-Level Verification System Language for describing systems

Inspired by CMU SMV

Symbolic simulatorGenerates integer expressions describing system state after

sequence of steps

Decision procedureDetermines validity of formulas

Support for multiple verification techniques

Available by DownloadAvailable by Downloadhttp://www.cs.cmu.edu/~uclid

– 10 –FLoC ‘06

Data Abstraction #1: Bits → IntegersData Abstraction #1: Bits → Integers

View Data as Symbolic WordsView Data as Symbolic Words Arbitrary integers

No assumptions about size or encodingClassic model for reasoning about software

Can store in memories & registers

x0

x1

x2

xn-1

x

– 11 –FLoC ‘06

Data PathData Path

Com.Log.

1

Com.Log.

2

Abstracting Data BitsAbstracting Data Bits

Control LogicControl Logic

Data PathData Path

Com.Log.

1

Com.Log.

1? ?

What do we do about logic functions?

– 12 –FLoC ‘06

Abstraction #2:Uninterpreted Functions

Abstraction #2:Uninterpreted Functions

For any Block that Transforms or Evaluates Data:For any Block that Transforms or Evaluates Data: Replace with generic, unspecified function Only assumed property is functional consistency:

a = x b = y f (a, b) = f (x, y)

ALUf

– 13 –FLoC ‘06

Abstracting FunctionsAbstracting Functions

For Any Block that Transforms Data:For Any Block that Transforms Data: Replace by uninterpreted function Ignore detailed functionality Conservative approximation of actual system

Data PathData Path

Control LogicControl Logic

Com.Log.

1

Com.Log.

1F1 F2

– 14 –FLoC ‘06

Abstraction #3: Modeling Memories as Mutable FunctionsAbstraction #3: Modeling Memories as Mutable Functions

Memory M Modeled as FunctionMemory M Modeled as Function

M(a): Value at location a

InitiallyInitially

Arbitrary state Modeled by uninterpreted function m0

Ma

M

a m0

– 15 –FLoC ‘06

Effect of Memory Write OperationEffect of Memory Write Operation

Writing Transforms MemoryWriting Transforms Memory M = Write(M, wa, wd)

Reading from updated memory:

Address wa will get wdOtherwise get what’s

already in M

Express with Lambda NotationExpress with Lambda Notation

M = a . ITE(a = wa, wd, M(a))

M

Ma 1

0

wd

=wa

– 16 –FLoC ‘06

Comparison to Array ModelingComparison to Array Modeling

Theory of ArraysTheory of Arrays Read operation

Read(M, a) Write operation

Write(M, wa, wd) Memory comparison

predicate

M1 = M2

Mutable FunctionsMutable Functions Function application

M(a) Lambda definition

a . ITE(a = wa, wd, M(a)) Content comparison

a . M1(a) = M2(a) Only feasible for positive

equality

Not limited to one dimension Lambda definition allows

other forms of updating

– 17 –FLoC ‘06

An Out-of-order Processor (OOO)An Out-of-order Processor (OOO)

Data Dependencies Resolved by Register RenamingData Dependencies Resolved by Register Renaming Map register ID to instruction in reorder buffer that will generate

register value

Inorder Retirement Managed by Retirement BufferInorder Retirement Managed by Retirement Buffer FIFO buffer keeping pending instructions in program order

Reorder BufferFields

PC

Programmemory

Reorder Buffer

validvaluesrc1validsrc1valsrc1tagsrc2validsrc2valsrc2tagdestop

result bus

DECODE Register

Rename Unit

valid tag val

ALU

head tail

incrdispatch

retire

execute

result

1st

Operand

2nd

Operand

– 18 –FLoC ‘06

ALU

execute

Directly AddressableDirectly Addressable Select particular entry for

execution Retrieve result value from

executed instruction

Access Modes for Reorder BufferAccess Modes for Reorder Buffer

FIFOFIFO Insert when dispatch Remove when retire

Content AddressableContent Addressable Broadcast result to all

entries with matching source tag

head tail

Retire Dispatch

result bus

GlobalGlobal Flush all queue entries when

instruction at head causes exception

– 19 –FLoC ‘06

Underlying LogicUnderlying LogicScalar Data TypesScalar Data Types

Formulas (F ) Boolean ExpressionsControl signals

Terms (T ) Integer ExpressionsData values

Functional Data TypesFunctional Data Types Functions (Fun) Integer Integer

Immutable: Functional unitsMutable: Memories

Predicates (P) Integer Boolean Immutable: Data-dependent controlMutable: Bit-level memories

– 20 –FLoC ‘06

CLU LogicCLU Logic Counter Arithmetic, Lambda Expressions and Uinterpreted

Functions

Terms (Terms (T T )) Integer ExpressionsInteger ExpressionsITE(F, T1, T2) If-then-else

Fun (T1, …, Tk) Function application

succ (T) Increment

pred (T) Decrement

Formulas (Formulas (F F )) Boolean ExpressionsBoolean ExpressionsF, F1 F2, F1 F2 Boolean connectives

T1 = T2 Equation

T1 < T2 Inequality

P(T1, …, Tk) Predicate applicationTo support pointer operations

– 21 –FLoC ‘06

CLU Logic (Cont.)CLU Logic (Cont.)Functions (Functions (FunFun)) Integer Integer Integer Integer

f Uninterpreted function symbol

x1, …, xk . T Function definition

Predicates (Predicates (PP)) Integer Integer Boolean Booleanp Uninterpreted predicate

symbol

x1, …, xk . F Predicate definition

– 22 –FLoC ‘06

UCLID Decision Procedure OperationUCLID Decision Procedure Operation

Series of transformations leading to propositional formula

Except for lambda expansion, each has polynomial complexity

LambdaExpansion

Function&

PredicateElimination

FiniteInstantiation

BooleanSatisfiability

CLUFormula

-freeFormula

TermFormula

BooleanFormula

– 23 –FLoC ‘06

System ModelSystem Model

State Variable TypesState Variable Types Boolean

Control signals

Integer Data, addresses

Function Memories, buffers

System OperationSystem Operation Synchronous

All state variables updated on each step of operation

Interleaving One (set of) state variable(s) updated at a time Simulate in synchronous model with uninterpreted scheduling function

PresentState

NextState

Inputs(Arbitrary)

Reset

– 24 –FLoC ‘06

OutlineOutline

Why Infinite State Systems?Why Infinite State Systems? Modeling capabilities of UCLID

Verification MethodsVerification Methods

ImplementationImplementation Advances in SAT and decision procedures

Prospects and ChallengesProspects and Challenges

– 25 –FLoC ‘06

ReachableStates

Verifying Safety PropertiesVerifying Safety Properties

Prove: System will never reach bad stateProve: System will never reach bad state

ResetStates

BadStates

PresentState

NextState

Inputs(Arbitrary)

Reset

– 26 –FLoC ‘06

Reachable

• • •

Rn

R2

Bounded Model CheckingBounded Model Checking

Repeatedly Perform Image Repeatedly Perform Image ComputationsComputations Set of all states reachable

by one more state transition

Easy to ImplementEasy to Implement

Underapproximation of Underapproximation of Reachable State SetReachable State Set But, typically catch most

bugs with 8–10 steps

BadStates

R1

ResetStates

– 27 –FLoC ‘06

Implementing BMCImplementing BMC

Construct verification condition formula for step n by symbolically simulating system for n cycles

Check with decision procedure Do as many cycles as tractable

S

X1 X2 Xn

Bad

ResetSatisfiable?

– 28 –FLoC ‘06

• • •

Rn

R2

True Model CheckingTrue Model Checking

Reach Fixed-PointReach Fixed-Point Rn = Rn+1 = Reachable

Impractical for Term-Level Impractical for Term-Level ModelsModels

Many systems never reach fixed point

Can keep adding elements to buffer

Convergence test undecidable

Bryant, Lahiri, Seshia, CHARME ‘03

BadStates

R1

ResetStates

– 29 –FLoC ‘06

I

Inductive Invariant CheckingInductive Invariant Checking

Key Properties of System that Make it Operate CorrectlyKey Properties of System that Make it Operate Correctly Formulate as formula I

Prove InductiveProve Inductive Holds initially I(s0)

Preserved by all state changes I(s) I((i, s))

ReachableStates

ResetStates

BadStates

– 30 –FLoC ‘06

Verification Example: OOOVerification Example: OOO


PC

Programmemory

Reorder Buffer


result bus

DECODE Register

Rename Unit

valid tag val

ALU

head tail

incrdispatch

retire

execute

result

1st

Operand

2nd

Operand

– 31 –FLoC ‘06

Verifying OOOVerifying OOO Lahiri, Seshia, & Bryant,

FMCAD 2002

GoalGoal Show that OOO implements

Instruction Set Architecture (ISA) model

For all possible execution sequences

ChallengeChallenge OOO holds partially executed

instructions in reorder bufferStates of two systems match

only when reorder buffer flushed

ISA

Reg.File

PC

OOO

Reg.File

PCReorder Buffer

– 32 –FLoC ‘06

Adding Shadow StateAdding Shadow State

McMillan, ‘98 Arons & Pnueli, ‘99

Provides Link Between ISA Provides Link Between ISA & OOO Models& OOO Models Additional info. in ROB

Does not affect OOO behavior

Generated when instruction dispatched

Predict values of operands and result

From ISA model

ISA

Reg.File

PC

OOO

Reg.File

PCReorder Buffer

– 33 –FLoC ‘06

State Consistency Invariants State Consistency Invariants

Register rename unit & reorder buffer encode same information redundantly

Rename Unit: Registers TagsReorder Buffer: Tags Registers


Reorder Buffer


RegisterRename Unit

valid tag val

head tail

dispatch

– 34 –FLoC ‘06


valid tag valdispatch

State Consistency Invariant Examples State Consistency Invariant Examples

Register Renaming invariants (2)Register Renaming invariants (2) Any mapped register should be in the ROB, and the

destination register should matchr.reg.valid(r)

(rob.head reg.tag(r) < rob.tail rob.dest(reg.tag(r)) = r )

For any ROB entry, the destination should have reg.valid as false and tag should be to this or later instructionrobt.[reg.valid(rob.dest(t))

t reg.tag(rob.dest(t)) reg.tag(rob.dest(t)) <

rob.tail]

– 35 –FLoC ‘06

Inductive InvariantsInductive Invariants

Formulas Formulas II11, …, , …, IInn

Ij(s0) holds for any initial state s0, for 1 j n

I1(s) I2(s) … In(s) Ij(s ) for any current state s and successor state s for 1 j n

Overall CorrectnessOverall Correctness Follows by induction on time

Restricted form of invariantsRestricted form of invariants x1x2…xk (x1…xk)

(x1…xk) is a CLU formula without quantifiers

x1…xk are integer variables free in (x1…xk) Express properties that hold for all buffer indices, register IDs, etc.

– 36 –FLoC ‘06

Proving InvariantsProving Invariants

Proving invariants inductive requires quantifiersProving invariants inductive requires quantifiers

|= [x1x2…xk (x1…xk)] [y1y2…ym (y1…ym)]

Prove unsatisfiability of formulaProve unsatisfiability of formulax1x2…xk (x1…xk) (y1…ym)

Undecidable ProblemUndecidable Problem In logic with uninterpreted functions and equality

– 37 –FLoC ‘06

Cooking with InvariantsCooking with InvariantsIngredients: Predicates

Recipe: Invariants

Result: Correctness

reg.valid(r)

r,t.reg.valid(r) reg.tag(r) = t (rob.head reg.tag(r) < rob.tail rob.dest(t) = r )

rob.head reg.tag(r)

reg.tag(r) = t

rob.dest(t) = r

– 38 –FLoC ‘06

Automatic Recipe GenerationAutomatic Recipe Generation

Want Something MoreWant Something More Given any set of ingredients Generate best recipe possible

Ingredients

Recipe Creator Result

– 39 –FLoC ‘06

Automatic Predicate AbstractionAutomatic Predicate Abstraction

Graf & Saïdi, CAV ‘97

IdeaIdea Given set of predicates p1(S), …, pk(S)

Boolean formulas describing properties of system state

View as abstraction mapping: States {0,1}k

Defines abstract FSM over state set {0,1}k

Form of abstract interpretationDo reachability analysis similar to symbolic model checking

ImplementationImplementation Early ones had weak inference capabilities

Call theorem prover or decision procedure to test each potential transition

Recent ones make better use of symbolic encodings

– 40 –FLoC ‘06

Abstract State SpaceAbstract State Space

ConcreteStates

AbstractStates

p1(s), …, pk(s)

s

AbstractionFunction

t

Abstraction

ConcreteStates

AbstractStates

s t

ConcretizationFunction

Concretization

– 41 –FLoC ‘06

Abstract State MachineAbstract State Machine

Transitions in abstract system mirror those in concrete

Abstract

ConcreteSystem

AbstractSystem

s

Concretize

t t

s

Concrete Transition

Abstract Transition

– 42 –FLoC ‘06

P.A. as Invariant GeneratorP.A. as Invariant Generator

Reach Fixed-Point on Reach Fixed-Point on Abstract SystemAbstract System Termination guaranteed,

since finite state

Equivalent to Computing Equivalent to Computing Invariant for Concrete Invariant for Concrete SystemSystem Strongest possible

invariant that can be expressed by formula over these predicates

• • •Rn

R2

R1

ResetStates

A

AbstractSystem

Concretize

ConcreteSystem

I

ResetStates

C

– 43 –FLoC ‘06

Symbolic Formulation of Predicate AbstractionSymbolic Formulation of Predicate Abstraction

TaskTask Predicates P = p1(S), …, pk(S)

Compute set of legal abstract next states (B) given current abstract states (B)B, B: Abstract current and next-state state variables

, : Boolean formulas

Lahiri, Bryant, Cook, CAV ‘03

AbstractSystem

(B)(B’

)

Abstract Transitions

– 44 –FLoC ‘06

Symbolic Formulation of P.A.Symbolic Formulation of P.A.ApproachApproach

Create formula of form (S,B)Possible combinations of current concrete state S and next abstract

state B

AbstractSystem

(B)

Concretize

[P/B]Concrete

System B’ P

GeneralConcretize

B P[/S] All Predecessors

(S,B): [P/B] BP[/S]

– 45 –FLoC ‘06

Symbolic Formulation of P.A.Symbolic Formulation of P.A.Computing Next-State SetComputing Next-State Set

Compute (B) S (S,B)Requires quantifier elimination

AbstractSystem

(B)

Concretize

[P/B]Concrete

System B’ P

GeneralConcretize

B P[/S] All Predecessors

(S,B): [P/B] BP[/S]

((BB) ) SS ((SS,,BB))

– 46 –FLoC ‘06

Quantified Invariant GenerationQuantified Invariant Generation(Lahiri & Bryant, VMCAI 2004) User supplies predicates containing free variables Generate globally quantified invariant

ExampleExample Predicates

p1: reg.valid(r)

p2: reg.tag(r) = t

p3: rob.dest(t) = r

Abstract state satisfying (p1 p2 p3) corresponds to concrete state satisfying r,t[reg.valid(r) reg.tag(r) = t

rob.dest(t) = r] rather than r[reg.valid(r)] r,t[reg.tag(r) = t]

r,t[rob.dest(t) = r]

– 47 –FLoC ‘06

OutlineOutline





– 48 –FLoC ‘06

Decision Procedure NeedsDecision Procedure Needs

Bounded Model CheckingBounded Model Checking Satisfiability of quantifier-free CLU formula Handled by decision procedure

Invariant CheckingInvariant Checking Satisfiability of quantified CLU formula Undecidable

Predicate AbstractionPredicate Abstraction Eliminate quantifiers from CLU formula

Role of Decision ProcedureRole of Decision Procedure Apply in sound, but incomplete way

– 49 –FLoC ‘06

SAT-based Decision ProceduresSAT-based Decision Procedures

Input Formula

Boolean Formula

satisfiable unsatisfiable

Satisfiability-preserving Boolean

Encoder

SAT Solver

EAGER ENCODING

Input Formula

Boolean Formula

satisfiable

unsatisfiable

Approximate Boolean Encoder

SAT Solver satisfying assignment

satisfiable

First-order Conjunctions SAT Checker

unsatisfiableadditional clause

LAZY ENCODING

– 50 –FLoC ‘06

Recent Progress in SAT SolvingRecent Progress in SAT Solving

766

147 118 81 46

3600

0

1,000

2,000

3,000

Gra

sp (2

000)

zChaf

f (200

1)

BerkM

in (2

002)

zChaf

f (200

3-04

)

Siege

(200

4)

SatElit

eGTI (

2005

)

Ru

n-t

ime

(sec

.)

Driven by annual SAT competitions

– 51 –FLoC ‘06

UCLID Decision ProcedureUCLID Decision Procedure

Eager approach

LambdaExpansion

Function&


FiniteInstantiation


CLUFormula

-freeFormula

TermFormula

BooleanFormula

– 52 –FLoC ‘06

Eager Encoding CharacteristicsEager Encoding Characteristics– Must encode all information about

domain properties into Boolean formula

– Some properties can give exponential blowup

+ Lets SAT solver do all of the work

Good Approach for Some DomainsGood Approach for Some Domains Modern SAT solvers have remarkable

capacityGood at extracting relevant portions out

of very large formulasLearns about formula properties as

search proceeds

Input Formula

Boolean Formula

satisfiable unsatisfiable

Satisfiability-preserving Boolean

Encoder

SAT Solver

– 53 –FLoC ‘06

DPLL(T)DPLL(T)

Ganzinger, Hagen, Nieuwenhuis, Oliveras, Tinell, CAV ‘04

Modular, Lazy Decision ProcedureModular, Lazy Decision Procedure Modern SAT solver as control loop Theory-specific solver (for theory T) plugs in

Compared to Other Lazy SolversCompared to Other Lazy Solvers Tighter coupling between DPLL engine & theory solver

DPLL

EngineTheory

Solver

FormulaTentative

PartialSolution

OK /Backtrack

Info.

– 54 –FLoC ‘06

DPLL(T) ExampleDPLL(T) Example g(a)c [f(g(a))f(c) g(a)d] cd

p1 [p2 p3] p4

ActionAction PropositionalPropositional TheoryTheory

Unit PropagateUnit Propagate p1g(a)c

Theory Theory PropagatePropagate

p2f(g(a))f(c)

Unit PropagateUnit Propagate p3g(a)d

Theory Theory PropogatePropogate

p4cd

(Failure)(Failure)

Formula

PropositionalForm

T = Equality with Uninterpreted Functions (EUF)

– 55 –FLoC ‘06

Invariant Checking RevisitedInvariant Checking Revisited

Prove Unsatisfiability of FormulaProve Unsatisfiability of Formulax1x2…xk (x1…xk) (y1…ym)

General Form: X (X) (Y)

Quantifier InstantiationQuantifier Instantiation Generate expressions E1(Y), …, En(Y)

Using terms that appear in View as a set of axioms that apply to terms in

Expand as (E1(Y)) … (En(Y)) (Y) If unsatisfiable, then so is quantified formulaSound, but incomplete

Trade-offTrade-off Be clever about instantiation, or Instantiate many terms and rely on decision procedure capacity

– 56 –FLoC ‘06

Versions of the OOO ProcessorVersions of the OOO Processor

baseExecutes ALU instructions only

excHandles arithmetic exceptionsMust flush reorder buffer

exc/brHandles branchesPredicts branch & speculatively executes along path

exc/br/mem-simpAdds load & store instructionsStore commits as instruction retires

exc/br/memStores held in bufferCan commit laterLoads must scan buffer for matching addresses

– 57 –FLoC ‘06

Comparative Verification EffortComparative Verification Effort

UCLID & Barcelona DPLL(T) decision proceduresMeasurements by Shuvendu Lahiri

Person time shown cumulatively

base exc exc / br exc / br / mem-simp

exc / br / mem

Total Invariants

13 34 39 67 71

UCLID time

54 s 236 s 403 s 1594 s 2200 s

DPLL(T) time

1 s 4 s 7 s 85 s

Person time

2 days 7 days 9 days 24 days 34 days

– 58 –FLoC ‘06

Predicate Abstraction RevisitedPredicate Abstraction Revisited

Formulate as Quantifier Elimination ProblemFormulate as Quantifier Elimination Problem Generate formula of form (B) S (S,B)

S: Integer variables

Solve by SAT EnumerationSolve by SAT Enumeration Find satisfying assignment (S) (B) for Record (B) as disjunct in Reformulate as (B)

ImplementationsImplementations UCLID

Do eager translation, then run incremental SAT solver

DPLL(T) [Lahiri, Nieuwenhuis, Oliveras, CAV ’06]Modify DPLL engine to backtrack when it finds solution

– 59 –FLoC ‘06

Systems Verified with Predicate AbstractionSystems Verified with Predicate Abstraction

Safety properties only

Model Predicates IterationsUCLID Time

DPLL(T) Time

Out-Of-Order Execution Unit 25 9 921s 36s

German’s Cache Protocol 16 9 34s 1s

German’s Protocol, unbounded channels

26 17 1,119s 23s

Lamport’s Bakery Algorithm 32 18 245s 11s

– 60 –FLoC ‘06

Why SAT Enumeration WorksWhy SAT Enumeration Works

Model with P predicates Number of abstract reachable states << 2P

Model Predicates States Fraction

Out-Of-Order Execution Unit 25 10,728 3 X 10-4

German’s Cache Protocol 16 326 5 X 10-3

German’s Protocol, unbounded channels

26 2,238 3 X 10-5

Lamport’s Bakery Algorithm 32 426 1 X 10-7

– 61 –FLoC ‘06

UCLID Counterexample GenerationUCLID Counterexample Generation

Counterexample Counterexample trace showing value

of each state variable on each step.

“Value” of a lambda is a set of argument/value pairs

Important feature for tool users

LambdaExpansion

Function&


FiniteInstantiation


SymbolicSimulation

TracePartial Interp.of Lambdas

Partial Interpretationof UIFs

IntegerAssignment

BooleanAssignment

– 62 –FLoC ‘06

Providing CounterexamplesProviding Counterexamples

Bounded CheckingBounded Checking Trace shows concrete failure case Could represent error in design, in model, or in specification

Invariant CheckingInvariant Checking Failure could be due to weak invariant or insufficient

quantifier instantiation

Predicate AbstractionPredicate Abstraction Does not provide useful counterexamples Generally yields abstract state “true”

– 63 –FLoC ‘06

OutlineOutline





– 64 –FLoC ‘06

Why Verification Tasks FeasibleWhy Verification Tasks Feasible

CLU Logic Fairly SimpleCLU Logic Fairly Simple Equality, uninterpreted functions, difference constraints Small model property

““Deep” Reasoning Not RequiredDeep” Reasoning Not Required Formulas large and messy, but straightforward Verifying systems that are designed to have constrained

behaviors Only checking effect of a few cycles of system operation

– 65 –FLoC ‘06

Future ProspectsFuture Prospects

EvaluationEvaluation Demonstrated ability to verify complex, parameterized

systems

Predicate Abstraction Shows PromisePredicate Abstraction Shows Promise Provides key automation advantage of model checking

Successful Application to Program VerificationSuccessful Application to Program Verification Qadeer & Lahiri, POPL ’06 Generate loop invariants for list manipulation programs

– 66 –FLoC ‘06

Areas of ResearchAreas of Research

Bit-Vector Decision ProceduresBit-Vector Decision Procedures True model for hardware & low-level software Automatically apply abstractions

Abstract to symbolic terms whenever possible

Other Types of VerificationOther Types of Verification Liveness properties

Abstraction must underapproximate concrete system

Certified correctnessExplanation-generating decision proceduresExtension to predicate abstraction engine

Counterexample generation Important for userHard to provide as raise level of abstraction & automation

Questions?Questions?

Carnegie Mellon University Formal Verification of Infinite-State Systems Using Boolean Methods Formal Verification of Infinite-State Systems Using Boolean.

Documents

data slide

system state

level state model state

use slide

bryant slide

state model checking

pipelined slide

finitestate models