Formal Verification of Pipelined Processors

1
Formal Verification of Infinite-State
Systems Using Boolean Methods
Randal E. Bryant
Carnegie Mellon University
http//www.cs.cmu.edu/bryant
2
Main Ideas

• Infinite 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
• Outline
• Why infinite state systems?
• UCLID modeling capabilities
• Verification methods
• Implementation
• Advances in SAT and decision procedures
• Prospects and challenges

3
Verification Example

• Task
• Verify that microprocessor correctly implements
  instruction set definition
• Even though heavily pipelined

Alpha 21264 Microprocessor Microprocessor Report,
Oct. 28, 1996
4
Verification Challenges

• Sources of Complexity
• Lots of internal state
• Complex control logic
• Opportunities
• Most of the logic serves to store, select, and
  communicate data

Alpha 21264 Microprocessor Microprocessor Report,
Oct. 28, 1996
5
Sources of Infinity

• Real-life computers are finite state
• Infinite-State Abstractions
• Traditional model for reasoning about programs
• Soundness depends on properties being verified
• Computer words
• Memory capacities

In Use



tail
head
6
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

In Use



tail
7
Existing Automatic Verification Methods

• Simulators, model checkers,
• All Operate at Bit Level
• State model
• State encoded as words and arrays of words
• Comprised of bits
• Must track how each bit of state gets updated
• Only Verify Single Instance of Design
• Fixed values for parameters
• Word size
• Buffer sizes
• Number of processes
• Some Work in Parameterized System Verification
• Exploit symmetries in system
• Limited applicability

8
What About Theorem Provers?

• Traditional Tool for Formal Verification
• Allow many forms of abstraction
• Hard to Use
• Lots of manual effort expertise required
• Question
• Can we incorporate some of these abstraction
  abilities into an automated tool?

9
UCLID

• Seshia, Lahiri, Bryant, CAV 02
• Term-Level Verification System
• Language for describing systems
• Inspired by CMU SMV
• Symbolic simulator
• Generates integer expressions describing system
  state after sequence of steps
• Decision procedure
• Determines validity of formulas
• Support for multiple verification techniques
• Available by Download
• http//www.cs.cmu.edu/uclid

10
Data Abstraction 1 Bits ? Integers
x0
x1
x2
xn-1

• View Data as Symbolic Words
• Arbitrary integers
• No assumptions about size or encoding
• Classic model for reasoning about software
• Can store in memories registers

11
Abstracting Data Bits
Control Logic
12
Abstraction 2 Uninterpreted Functions
f

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

13
Abstracting Functions
Control Logic
Data Path
Com. Log. 1
Com. Log. 1

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

14
Abstraction 3 Modeling Memories as Mutable
Functions

• Memory M Modeled as Function
• M(a) Value at location a
• Initially
• Arbitrary state
• Modeled by uninterpreted function m0

15
Effect of Memory Write Operation

• Writing Transforms Memory
• M? Write(M, wa, wd)
• Reading from updated memory
• Address wa will get wd
• Otherwise get whats already in M

• Express with Lambda Notation
• M?
• ? a . ITE(a wa, wd, M(a))

16
Comparison to Array Modeling

• Theory of Arrays
• Read operation
• Read(M, a)
• Write operation
• Write(M, wa, wd)
• Memory comparison predicate
• M1 M2

• Mutable 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
An Out-of-order Processor (OOO)
valid tag val
D E C O D E
incr
dispatch
Program memory
valid value src1valid src1val src1tag src2valid sr
c2val src2tag dest op
result
PC
Register Rename Unit
1st Operand
result bus
retire
2nd Operand
ALU

Reorder Buffer
execute
head
tail
Reorder Buffer Fields

• Data Dependencies Resolved by Register Renaming
• Map register ID to instruction in reorder buffer
  that will generate register value
• Inorder Retirement Managed by Retirement Buffer
• FIFO buffer keeping pending instructions in
  program order

18
Access Modes for Reorder Buffer

• FIFO
• Insert when dispatch
• Remove when retire

• Content Addressable
• Broadcast result to all entries with matching
  source tag

• Global
• Flush all queue entries when instruction at head
  causes exception

19
Underlying Logic

• Scalar Data Types
• Formulas (F ) Boolean Expressions
• Control signals
• Terms (T ) Integer Expressions
• Data values
• Functional Data Types
• Functions (Fun) Integer ? Integer
• Immutable Functional units
• Mutable Memories
• Predicates (P) Integer ? Boolean
• Immutable Data-dependent control
• Mutable Bit-level memories

20
CLU Logic

• Counter Arithmetic, Lambda Expressions and
  Uinterpreted Functions
• Terms (T ) Integer Expressions
• ITE(F, T1, T2) If-then-else
• Fun (T1, , Tk) Function application
• succ (T) Increment
• pred (T) Decrement
• Formulas (F ) Boolean Expressions
• ?F, F1 ? F2, F1 ? F2 Boolean connectives
• T1 T2 Equation
• T1 lt T2 Inequality
• P(T1, , Tk) Predicate application

21
CLU Logic (Cont.)

• Functions (Fun) Integer ? Integer
• f Uninterpreted function symbol
• ? x1, , xk . T Function definition
• Predicates (P) Integer ? Boolean
• p Uninterpreted predicate symbol
• ? x1, , xk . F Predicate definition

22
UCLID Decision Procedure Operation
CLU Formula
Lambda Expansion
?-free Formula

• Series of transformations leading to
  propositional formula
• Except for lambda expansion, each has polynomial
  complexity

Function Predicate Elimination
Term Formula
Finite Instantiation
Boolean Formula
Boolean Satisfiability
23
System Model

• State Variable Types
• Boolean
• Control signals
• Integer
• Data, addresses
• Function
• Memories, buffers
• System 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

24
Outline

• Why Infinite State Systems?
• Modeling capabilities of UCLID
• Verification Methods
• Implementation
• Advances in SAT and decision procedures
• Prospects and Challenges

25
Verifying Safety Properties
Bad States
Reachable States
Reset States
Reset

• Prove System will never reach bad state

26
Bounded Model Checking
Bad States
R2

• Repeatedly Perform Image Computations
• Set of all states reachable by one more state
  transition
• Easy to Implement
• Underapproximation of Reachable State Set
• But, typically catch most bugs with 810 steps

R1
Reset States
27
Implementing BMC
Satisfiable?

• Construct verification condition formula for step
  n by symbolically simulating system for n cycles
• Check with decision procedure
• Do as many cycles as tractable

28
True Model Checking
Bad States
R2

• Impractical for Term-Level Models
• Many systems never reach fixed point
• Can keep adding elements to buffer
• Convergence test undecidable
• Bryant, Lahiri, Seshia, CHARME 03

R1
Reset States

• Reach Fixed-Point
• Rn Rn1 Reachable

29
Inductive Invariant Checking
Bad States
Reachable States
Reset States

• Key Properties of System that Make it Operate
  Correctly
• Formulate as formula I
• Prove Inductive
• Holds initially I(s0)
• Preserved by all state changes I(s) ? I(?(i, s))

30
Verification Example OOO
valid tag val
D E C O D E
incr
dispatch
Program memory
valid value src1valid src1val src1tag src2valid sr
c2val src2tag dest op
result
PC
Register Rename Unit
1st Operand
result bus
retire
2nd Operand
ALU

Reorder Buffer
execute
head
tail
Reorder Buffer Fields
31
Verifying OOO

• Lahiri, Seshia, Bryant, FMCAD 2002
• Goal
• Show that OOO implements Instruction Set
  Architecture (ISA) model
• For all possible execution sequences
• Challenge
• OOO holds partially executed instructions in
  reorder buffer
• States of two systems match only when reorder
  buffer flushed

32
Adding Shadow State

• McMillan, 98
• Arons Pnueli, 99
• Provides Link Between ISA OOO Models
• Additional info. in ROB
• Does not affect OOO behavior
• Generated when instruction dispatched
• Predict values of operands and result
• From ISA model

OOO
Reg. File
PC
Reorder Buffer
33
State Consistency Invariants

• Register rename unit reorder buffer encode same
  information redundantly
• Rename Unit Registers ? Tags
• Reorder Buffer Tags ? Registers

34
State Consistency Invariant Examples

• Register Renaming invariants (2)
• Any mapped register should be in the ROB, and the
  destination register should match
• ?r.?reg.valid(r)?
• (rob.head ? reg.tag(r) lt 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 instruction
• ?robt.?reg.valid(rob.dest(t)) ?
• t ? reg.tag(rob.dest(t)) ?
• reg.tag(rob.dest(t)) lt rob.tail

35
Inductive Invariants

• Formulas I1, , In
• 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 Correctness
• Follows by induction on time
• Restricted form of invariants
• ?x1?x2?xk ?(x1xk)
• ?(x1xk) is a CLU formula without quantifiers
• x1xk are integer variables free in ?(x1xk)
• Express properties that hold for all buffer
  indices, register IDs, etc.

36
Proving Invariants

• Proving invariants inductive requires quantifiers
• ?x1?x2?xk ?(x1xk) ? ?y1?y2?ym ?(y1ym)
  
• Prove unsatisfiability of formula
• ?x1?x2?xk ?(x1xk) ? ??(y1ym)
• Undecidable Problem
• In logic with uninterpreted functions and equality

37
Cooking with Invariants
Ingredients Predicates
rob.head ? reg.tag(r)
Recipe Invariants
?r,t.?reg.valid(r) ? reg.tag(r) t ?
(rob.head ? reg.tag(r) lt rob.tail ?
rob.dest(t) r )
reg.valid(r)
reg.tag(r) t
Result Correctness
rob.dest(t) r
38
Automatic Recipe Generation
Ingredients
Result
Recipe Creator

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

39
Automatic Predicate Abstraction

• Graf Saïdi, CAV 97
• Idea
• Given set of predicates p1(S), , pk(S)
• Boolean formulas describing properties of system
  state
• View as abstraction mapping States ? 0,1k
• Defines abstract FSM over state set 0,1k
• Form of abstract interpretation
• Do reachability analysis similar to symbolic
  model checking
• Implementation
• 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
Abstract State Space
Abstraction
Concretization
Abstract States
Abstract States
Concrete States
Concrete States
41
Abstract State Machine
Abstract System
Concrete System

• Transitions in abstract system mirror those in
  concrete

42
P.A. as Invariant Generator

• Reach Fixed-Point on Abstract System
• Termination guaranteed, since finite state
• Equivalent to Computing Invariant for Concrete
  System
• Strongest possible invariant that can be
  expressed by formula over these predicates

Abstract System
43
Symbolic Formulation of Predicate Abstraction
Lahiri, Bryant, Cook, CAV 03

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

?(B)
Abstract System
44
Symbolic Formulation of P.A.

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

?(B)
Abstract System
Concrete System
B?? P?/S
All Predecessors
45
Symbolic Formulation of P.A.

• Computing Next-State Set
• Compute ??(B?) ? ? S ?(S,B?)
• Requires quantifier elimination

?(B)
Abstract System
Concrete System
B?? P?/S
All Predecessors
46
Quantified Invariant Generation

• (Lahiri Bryant, VMCAI 2004)
• User supplies predicates containing free
  variables
• Generate globally quantified invariant
• Example
• 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,treg.tag(r) t ?
• ?r,trob.dest(t) r

47
Outline

• Why Infinite State Systems?
• Modeling capabilities of UCLID
• Verification Methods
• Implementation
• Advances in SAT and decision procedures
• Prospects and Challenges

48
Decision Procedure Needs

• Bounded Model Checking
• Satisfiability of quantifier-free CLU formula
• Handled by decision procedure
• Invariant Checking
• Satisfiability of quantified CLU formula
• Undecidable
• Predicate Abstraction
• Eliminate quantifiers from CLU formula
• Role of Decision Procedure
• Apply in sound, but incomplete way

49
SAT-based Decision Procedures
50
Recent Progress in SAT Solving
Driven by annual SAT competitions
51
UCLID Decision Procedure
CLU Formula
Lambda Expansion
?-free Formula
Function Predicate Elimination
Term Formula

• Eager approach

Finite Instantiation
Boolean Formula
Boolean Satisfiability
52
Eager 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 Domains
• Modern SAT solvers have remarkable capacity
• Good at extracting relevant portions out of very
  large formulas
• Learns about formula properties as search proceeds

53
DPLL(T)

• Ganzinger, Hagen, Nieuwenhuis, Oliveras, Tinell,
  CAV 04
• Modular, Lazy Decision Procedure
• Modern SAT solver as control loop
• Theory-specific solver (for theory T) plugs in
• Compared to Other Lazy Solvers
• Tighter coupling between DPLL engine theory
  solver

54
DPLL(T) Example

g(a)?c ? f(g(a))?f(c) ? g(a)?d ? c?d
p1 ? ?p2 ? p3 ? ?p4
Formula
Propositional Form
Action Propositional Theory
Unit Propagate p1 g(a)?c
Theory Propagate p2 f(g(a))?f(c)
Unit Propagate p3 g(a)?d
Theory Propogate p4 c?d
(Failure)
T Equality with Uninterpreted Functions (EUF)
55
Invariant Checking Revisited

• Prove Unsatisfiability of Formula
• ?x1?x2?xk ?(x1xk) ? ??(y1ym)
• General Form ?X ?(X) ? ??(Y)
• Quantifier 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 formula
• Sound, but incomplete
• Trade-off
• Be clever about instantiation, or
• Instantiate many terms and rely on decision
  procedure capacity

56
Versions of the OOO Processor

• base
• Executes ALU instructions only
• exc
• Handles arithmetic exceptions
• Must flush reorder buffer
• exc/br
• Handles branches
• Predicts branch speculatively executes along
  path
• exc/br/mem-simp
• Adds load store instructions
• Store commits as instruction retires
• exc/br/mem
• Stores held in buffer
• Can commit later
• Loads must scan buffer for matching addresses

57
Comparative Verification Effort

• UCLID Barcelona DPLL(T) decision procedures
• Measurements 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
Predicate Abstraction Revisited

• Formulate as Quantifier Elimination Problem
• Generate formula of form ??(B?) ? ? S
  ?(S,B?)
• S Integer variables
• Solve by SAT Enumeration
• Find satisfying assignment ?(S) ? ?(B?) for ?
• Record ?(B?) as disjunct in ??
• Reformulate ? as ? ? ??(B?)
• Implementations
• 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
Systems Verified with Predicate Abstraction
Model Predicates Iterations UCLID Time DPLL(T) Time
Out-Of-Order Execution Unit 25 9 921s 36s
Germans Cache Protocol 16 9 34s 1s
Germans Protocol, unbounded channels 26 17 1,119s 23s
Lamports Bakery Algorithm 32 18 245s 11s

• Safety properties only

60
Why SAT Enumeration Works
Model Predicates States Fraction
Out-Of-Order Execution Unit 25 10,728 3 X 10-4
Germans Cache Protocol 16 326 5 X 10-3
Germans Protocol, unbounded channels 26 2,238 3 X 10-5
Lamports Bakery Algorithm 32 426 1 X 10-7

• Model with P predicates
• Number of abstract reachable states ltlt 2P

61
UCLID Counterexample Generation
Symbolic Simulation
Trace
Partial Interp. of Lambdas
Lambda Expansion
Partial Interpretation of UIFs

• 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

Function Predicate Elimination
Integer Assignment
Finite Instantiation
Boolean Assignment
Boolean Satisfiability
62
Providing Counterexamples

• Bounded Checking
• Trace shows concrete failure case
• Could represent error in design, in model, or in
  specification
• Invariant Checking
• Failure could be due to weak invariant or
  insufficient quantifier instantiation
• Predicate Abstraction
• Does not provide useful counterexamples
• Generally yields abstract state true

63
Outline

• Why Infinite State Systems?
• Modeling capabilities of UCLID
• Verification Methods
• Implementation
• Advances in SAT and decision procedures
• Prospects and Challenges

64
Why Verification Tasks Feasible

• CLU Logic Fairly Simple
• Equality, uninterpreted functions, difference
  constraints
• Small model property
• Deep 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
Future Prospects

• Evaluation
• Demonstrated ability to verify complex,
  parameterized systems
• Predicate Abstraction Shows Promise
• Provides key automation advantage of model
  checking
• Successful Application to Program Verification
• Qadeer Lahiri, POPL 06
• Generate loop invariants for list manipulation
  programs

66
Areas of Research

• Bit-Vector Decision Procedures
• True model for hardware low-level software
• Automatically apply abstractions
• Abstract to symbolic terms whenever possible
• Other Types of Verification
• Liveness properties
• Abstraction must underapproximate concrete system
• Certified correctness
• Explanation-generating decision procedures
• Extension to predicate abstraction engine
• Counterexample generation
• Important for user
• Hard to provide as raise level of abstraction
  automation

67

• Questions?