carnegie mellon university formal verification of infinite-state systems using boolean methods...
Post on 27-Mar-2015
221 Views
Preview:
TRANSCRIPT
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
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
– 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 BufferFields
Reorder Buffer
validvaluesrc1validsrc1valsrc1tagsrc2validsrc2valsrc2tagdestop
RegisterRename Unit
valid tag val
head tail
dispatch
– 34 –FLoC ‘06
validvaluesrc1validsrc1valsrc1tagsrc2validsrc2valsrc2tagdestop
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
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
– 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&
PredicateElimination
FiniteInstantiation
BooleanSatisfiability
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&
PredicateElimination
FiniteInstantiation
BooleanSatisfiability
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
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
– 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?
top related