1. Carnegie Mellon University Formal Verification Using Infinite-State Models Formal Verification Using Infinite-State Models http://www.cs.cmu.edu/~bryant Randal E. Bryant Contributions by graduate students: Miroslav Velev, Sanjit Seshia, Shuvendu Lahiri

2. – 2 – Outline Task Formally verify hardware and software systems Build on success in verifying finite models Infinite-State Models How do they arise Need logic that is suitably expressive, yet remains reasonably tractable. Verification Techniques Range of methods with varying capabilities and limitations Solve problems by mapping into propositional logic Proof engines can use powerful Boolean methods

3. – 3 – Microprocessor Report, Oct. 28, 1996 Example: HP/Compaq Alpha 21264 Pipeline State Multiple caches Instruction queues Dynamically- allocated registers Memory queue Many buffers between stages Verification Tasks Does it implement the Alpha ISA? Do specific units satisfy desired properties?

4. – 4 – Temporal Logic Model Checking Verify Reactive Systems Construct state machine representation of reactive system Nondeterminism expresses range of possible behaviors “Product” of component state machines Express desired behavior as formula in temporal logic Determine whether or not property holds Traffic Light Controller Design Traffic Light Controller Design “It is never possible to have a green light for both N-S and E-W.” Model Checker True False + Counterexample

5. – 5 – Finite System Modeling Example Distributed, Shared Memory System Simplifying Abstractions Single word cache Single bit/word Abstract other clusters Imprecise timing Interface Cluster #2 Abstraction Cluster #3 Abstraction Interface Mem. Cache Control. Cache Control. Global Bus Cluster #1 Bus Proc. Arbitrary reads & writes

6. – 6 – Symbolic FSM Analysis Example K. McMillan, E. Clarke (CMU) J. Schwalbe (Encore Computer) Encore Gigamax Cache System Distributed memory multiprocessor Cache system to improve access time Complex hardware and synchronization protocol.Verification Create “simplified” finite state model of system (10 9 states!) Verify properties about set of reachable states Bug Detected Sequence of 13 bus events leading to deadlock With random simulations, would require  2 years to generate failing case. In real system, would yield MTBF < 1 day.

7. – 7 – (x 1  x 2 )  x 3 Nodes represent variable tests Branches represent variable values Dashed for value 0 Solid for value 1 Canonical representation when reduction rules applied Makes equivalence trivial Boolean Manipulation with OBDDs Ordered Binary Decision Diagrams Data structure for representing Boolean functions Key to success in hardware verificationExample:

8. – 8 – Representing Circuit Functions Functions All outputs of 4-bit adder Functions of data inputs Shared Representation Graph with multiple roots 31 nodes for 4-bit adder 571 nodes for 64-bit adder  Linear growth

9. – 9 – Reg. File IF/ID Instr Mem +4 PC ID/EX ALUALU EX/WB = = Rd Ra Rb Imm Op Adat Control Bdat Simplified Processor Example Simplified RISC pipeline Register-Register and Register-Immediate operations Data hazards handled by register forwarding Each step of operation defined by function  pipe

10. – 10 – Reg. File Instr Mem +4 ALUALU Rd Ra Rb Imm Op Adat Control Bdat ISA Reference Model Only programmer-visible state Much simpler control logic Assume verified against instruction set definition Each step of operation defined by function  spec PC

11. – 11 – Abstracting Data from Bits to Integers View Data as Symbolic “Terms” Arbitrary integers Verification proves correctness of design for all possible word sizes Can store in memories & registers Can select with multiplexors ITE: If-Then-Else operation x0x0 x1x1 x2x2 x n-1 x  1010 x y p ITE(p, x, y) 1010 x y T x 1010 x y F y

12. – 12 – Abstraction Via Uninterpreted Functions 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) ALUALU f

13. – 13 – Abstraction Via Uninterpreted Functions For any Block that Transforms or Evaluates Data: Replace with generic, unspecified function Also view instruction memory as function Reg. File IF/ID Instr Mem +4 PC ID/EX ALUALU EX/WB = = Rd Ra Rb Imm Op Adat Control F1F1 F2F2 F3F3

14. – 14 – Reg. File Instr Mem +4 ALUALU Rd Ra Rb Imm Op Adat Control Bdat PC F1F1 F2F2 F3F3 Abstracting Reference Model Abstract with identical functions as in pipeline model

15. – 15 – EUF: Equality with Uninterp. Functs Decidable fragment of first order logic Formulas ( F ) Boolean Expressions  F, F 1  F 2, F 1  F 2 Boolean connectives T 1 = T 2 Equation P (T 1, …, T k ) Predicate application Terms ( T ) Integer Expressions ITE(F, T 1, T 2 ) If-then-else Fun (T 1, …, T k ) Function application Functions ( Fun ) Integer  Integer f Uninterpreted function symbol Read, Write Memory operations Predicates ( P ) Integer  Boolean p Uninterpreted predicate symbol

16. – 16 – Correctness of Pipeline Abstraction Function Abs Relates state of pipeline to program state Result of completing partially-executed instructionsRequirement Pipeline step  pipe matches k instruction executions  k spec For our pipeline k = 1 When pipeline stalls have k =0 Superscalar pipelines can have k > 1 Q pipe  pipe Abs Q spec  k spec Abs

17. – 17 – Correspondence Checking Burch & Dill, Computer-Aided Verification ‘94 Exploit State Structure State held in memories and pipeline latches Memories match those of instruction set model Latches hold additional pipeline state Pipeline State can be “flushed” Control logic to support external interrupts Complete in-flight instructions Without fetching any new ones

18. – 18 – Computing Abstraction Function Method Start with arbitrary pipeline state Q pipe Symbolically simulate processor with stall asserted Project out all but programmer-visible stateEffect Processor computes its own abstraction function! Arbitrary Q pipe  pipe Stall = 1  pipe Stall = 1 Q spec Proj  pipe Stall = 1 Pipeline Flushed

19. – 19 – Computational Task: Single-Issue Processor Compare results of two symbolic simulations Starting from same initial state Number of simulation steps ~ pipeline depth Check that resulting user-visible states identical Disjunctive acceptance condition Extra clock cycle causes either 0 or 1 new instructions to complete Q pipe  pipe Stall = 1 Proj  pipe Stall = 1  pipe Stall= 0  pipe Stall= 1  pipe Stall= 1 Proj  spec =?  k=0 k=1

20. – 20 – Computational Task: Dual-Issue Processor Extra clock cycle causes 0, 1, or 2 new instructions to complete  spec =?  k=0 k=1 Q pipe  pipe Stall= 0 Proj Flush Proj  spec =? k=2

21. – 21 – ALUALU Ra Rb T = 0 x a x b ALUALU Ra Rb T = 1 x a x b f Term-Level Symbolic Simulation ALUALU Ra Rb T = 2 x a x b ff ALUALU Ra Rb T = 3 x a x b fff Simulator Operation Register states are term-level expressions Denoted by pointers to nodes in Directed Acyclic Graph (DAG) Simulate each cycle of circuit by adding new nodes to DAG Based on circuit operations Construct DAG denoting correctness condition

22. – 22 – Decision Problem Logic of Equality with Uninterpreted Functions (EUF) Truth Values Dashed Lines Model Control Logical connectives Equations Integer Values Solid lines Model Data Uninterpreted functions If-Then-Else operationTask Determine whether formula is universally valid True for all interpretations of variables and function symbols

23. – 23 – Finite Model Property for EUF Observation Any formula has limited number of distinct expressions Only property that matters is whether or not different terms are equal x0x0 d0d0 f (x0)f (x0) f (d0)f (d0)

24. – 24 – Boolean Encoding of Integer Values For Each Expression Either equal to or distinct from each preceding expression Boolean Encoding Use Boolean values to encode integers over small range EUF formula can be translated into propositional logic Tautology iff original formula valid Expression Possible Values Bit Encoding x0x0{0}00 d0d0{0,1}0 b 10 f (x0)f (x0){0,1,2} b 21 b 20 f (d0)f (d0){0,1,2,3} b 31 b 30

25. – 25 – Benchmark Circuits Single Issue Pipeline: 1xDLX Analogous to DLX model in Hennessy & Patterson Verified in ‘94 by Burch & Dill Dual Issue Pipeline : 2xDLX-CC Superscalar operation with two complete pipelines Full-Featured Pipeline: 2xDLX-* Multi-cycle function units, exception handling & branch prediction

26. – 26 – Evaluation Using BDD Evaluation to Prove Tautology CircuitBDD Vars.BDD NodesCPU Secs. 1xDLX632,1270.2 2xDLX-CC17351,82620 2xDLX-*418986,7402,635 Using SAT Checkers to Prove Tautology Chaff (Malik, Princeton) Major advances in last few years CircuitCNF Vars.ClausesCPU Secs. 2xDLX-*4,58341,70422

27. – 27 – An Out-of-order Processor (OOO) Data Dependencies Resolved by Register Renaming Mapping from 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 Reorder Buffer Fields PC Program memory Reorder Buffer valid value src1valid src1val src1tag src2valid src2val src2tag dest op result bus DECODEDECODE Register Rename Unit valid tag val ALU headtail incr dispatch retire execute result 1 st Operand 2 nd Operand

28. – 28 – ALU execute Directly Addressable Select particular entry for execution Retrieve result value from executed instruction Access Modes for Reorder Buffer FIFO Insert when dispatch Remove when retire Content Addressable Broadcast result to all entries with matching source tag headtail RetireDispatch result busGlobal Flush all queue entries when instruction at head causes exception

29. – 29 – Required Logic Increased Expressive Power Model queue pointers Increment & decrement operations Relative ordering Ability to construct complex memory structures Not just set of fixed memory types Don’t Go Too Far Want practical decision procedures Efficient reduction to propositional logic

30. – 30 – EUF  CLU Terms ( T ) ITE(F, T 1, T 2 ) If-then-else Fun (T 1, …, T k ) Function application Formulas ( F )  F, F 1  F 2, F 1  F 2 Boolean connectives T 1 = T 2 Equation P(T 1, …, T k ) Predicate application succ (T) Increment pred (T) Decrement T 1 < T 2 Inequality

31. – 31 – EUF  CLU (Cont.) Functions ( Fun ) f Uninterpreted function symbol Read, Write Memory operations Predicates ( P ) p Uninterpreted predicate symbol x 1, …, x k. T Function lambda expression x 1, …, x k. F Predicate lambda expression Arguments can only be terms Lambdas are just mutable arrays

32. – 32 – Modeling Memories with ’s Memory M Modeled as Function M(a): Value at location aInitially Arbitrary state Modeled by uninterpreted function m 0 Writing Transforms Memory M = Write(M, wa, wd) a. ITE(a = wa, wd, M(a)) Future reads of address wa will get wd M a M a m0m0 M M a 1010 wd = wa

33. – 33 – Modeling Unbounded FIFO Buffer Queue is Subrange of Infinite Sequence Q.head = h Index of oldest element Q.tail = t Index of insertion location Q.val = q Function mapping indices to values q(i) valid only when h  i < t Initial State: Arbitrary Queue Q.head = h 0, Q.tail = t 0 Impose constraint that h 0  t 0 Q.val = q 0 Uninterpreted function q(h–2) q(h–1) q(h) q(h+1) q(t–2) q(t–1) q(t) q(t+1) tail head Already Popped Not Yet Inserted increasing indices

34. – 34 – Modeling FIFO Buffer (cont.) t q(h–2) q(h–1) q(h) q(h+1) q(t–2) q(t–1) q(t) q(t+1) h next[h] := ITE(operation = POP, succ(h), h) next[q] := (i). ITE((operation = PUSH & i=t), x, q(i)) next[t] := ITE(operation = PUSH, succ(t), t) q(h–2) q(h–1) q(h) q(h+1) q(t–2) q(t–1) x q(t+1) next[t] next[h] op = PUSH Input = x

35. – 35 – Decision Procedure Operation Series of transformations leading to propositional formula Propositional formula checked with BDD or SAT tools Bryant, Lahiri, Seshia [CAV02] Lambda Expansion Function & Predicate Elimination Convert to Boolean Formula Boolean Satisfiability CLU Formula -free Formula Function-free Formula Boolean Formula

36. – 36 – Finite Model Property for CLU Observation Need to encode all possible relative orderings of expressions Each symbolic value has maximum range of increments & decrements Can use Boolean encodings of small integer ranges x  y  succ(x) > pred(y) xx+1 y –1y y xx+1 y –1y xx+1 y –1y xx+1x y –1y x = 0, y = 3x = 2, y = 1

37. – 37 – Verification Techniques in UCLID Bounded Property Checking Start in reset state Symbolically simulate for fixed number of steps Verify a safety property for all states reachable within the fixed number of steps from the start state Correspondence Checking Run 2 different simulations starting in most general state Prove that final states equivalent e.g. Burch-Dill Technique Invariant Checking Start in general state s Prove Inv(s)  Inv(next[s]) Limited support for automatic quantifier instantiation

38. – 38 – Verification of OOO : Automation vs. Guarantee Presence of decision procedure Efficiency : Allows improved bounded property checking and Burch-Dill method Automation : Reduces manual guidance in proving invariants Automatic Instantiation of quantifiers MethodResourcesVerification (# of steps) Auxiliary variables Invariants Bounded Property Checking UnboundedBoundedNone Burch-Dill Technique FixedUnboundedNoneVery few Inductive Invariant Checking Unbounded SignificantSignificant, including those for auxiliary variables

39. – 39 – Technique 1 : Bounded Property Checking Debugging OOO using Bounded Property Checking All the errors were discovered during this phase Counterexample trace of great help Debugging Motorola ELF™ Superscalar out-of-order processor Reorder Buffer, memory unit, load-store queues etc. Applied during early design exploration phase

40. – 40 – Bounded Property Checking Results SVC (Stanford) : Another decision procedure to solve CLU formulas Can decide more expressive class CVC (Successor of SVC) runs out of memory on larger cases Modelstepsterms Term formula size Prop Formula Size UCLID time (s) SVC time (s) OOO unit 105925661529010.8233.18 148774806250476.55> 5 hrs 20129199212634131679.12> 1 day Elf™6332189421.210.9 870108544818.41851.6 1010424671645330.6> 1 day 12149455354288111.0> 1 day

41. – 41 – Burch-Dill Technique for OOO Exponential blowup with the number of ROB entries Limited to r = 8 entries currently r = 8 finished after case-splitting in 2.5hrs # Of ROB Entries # of terms Term formula size Prop Formula Size UCLID time (s) 26339853256.83 3836181024830.23 410388618175157.41 61431534412083051.79 8183234282915>31hrs

42. – 42 – Technique 3 : Invariant Checking Deriving the inductive invariants Require additional (auxiliary) variables to express invariants Auxiliary variables do not affect system operation Proving that the invariants are inductive Automate proof of invariants in UCLID Eliminates need for large (often fragile) proof script

43. – 43 – Restricted Invariants and Proofs Restricted classes of invariants  x 1  x 2 …  x k  (x 1 …x k )  (x 1 …x k ) is a CLU formula without quantifiers x 1 …x k are integer variables free in  (x 1 …x k ) Proving these invariants requires quantifiers  x 1  x 2 …  x k  (x 1 …x k )   y 1  y 2 …  y m  (y 1 …y m )  x 1  x 2 …  x k  y 1  y 2 …  y m [   (x 1 …x k )   (y 1 …y m ) ] Automatic instantiation of with concrete terms Automatic instantiation of x 1 …x k with concrete terms Sound but incomplete method Reduce the quantified formula to a CLU formula Can use the decision procedure for CLU

44. – 44 – Proving Invariants Proved automatically Quantifier instantiation was sufficient in these cases Relieves the user of writing proof scripts to discharge the proofs Time spent = 54s on 1.4GHz m/c Total effort = 2 person days

45. – 45 – Extending the Design 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

46. – 46 – Comparative Verification Effort baseexcexc / brexc / br / mem-simp exc / br / mem Total Invariants 1334396771 Manually instantiate 00048 UCLID time 54 s236 s403 s1594 s2200 s Person time 2 days5 days2 days15 days10 days

47. – 47 – Beyond Processor Verification Systems of Identical Processes E.g., synchronization protocols Arbitrary number of processes, each having same operationSoftware Create finite model by predicate abstraction

48. – 48 – Systems of Identical Processes Each Process has k State Variables Each state variable represented as array Indexed by process Id sv 1 sv 2 sv k State of Process i

49. – 49 – Modeling System of Identical Processes On Each Step: Select arbitrary process index p As if chosen by nondeterministic scheduler Update state for selected process next[state] := lambda(i) case i = p & state(i) = IDLE: TRYING i = p & state(i) = TRYING & inuse : TRYING i = p & state(i) = TRYING & !inuse: CRITICAL default: state(i) esac IDLE TRYING CRITICAL state 0/1 inusep

50. – 50 – Model Checking Software Program is Hard to Model as Finite-State Machine Large number of large data words means lots of bits Although “finite”, bound is very large Recursion requires stack Conceptually unbounded Creating Finite State Abstraction Microsoft SLAM verifier Focus on device drivers Start with very abstract model of program Every conditional can arbitrarily be taken/not-taken Check properties E.g., always close files Refine when find counterexample More careful analysis of conditionals

51. – 51 – Code Verification Example Adapted by Tom Ball from PCI device driver code Initial verification run based on simple model of control flow do { lock(v); old = new; if (test()) { unlock(v); new++; } } while (new != old); unlock(v); Properties to Check Cannot unlock v unless locked Cannot lock v unless unlocked Must exit code with v unlocked

52. – 52 – Model as Boolean Program All conditionals abstracted as Boolean variables Allows arbitrary branching Finite-state approximation of program do { lock(); if (a) { unlock(); } } while (b); unlock(); Apparent bug: May call unlock twice Apparent bug: May call lock twice

53. – 53 – Refining Abstraction Add more detail to model to prove that errors do not occur Use lightweight theorem prover to check do { lock(); old = new; if (test()) { unlock(); new++; } } while (new != old); unlock(); old = new do { lock(); if (a) { unlock(); } } while (b); unlock(); Double locking !a  !b !a!a b

54. – 54 – Refining Abstraction (cont.) Continue using counterexamples to generate more constraints on allowed state transitions do { lock(); old = new; if (test()) { unlock(); new++; } } while (new != old); unlock(); Double unlocking do { lock(); old = new; if (a) { unlock(); new++; } } while (b); unlock(); old  new old = new a  b a !b!b

55. – 55 – Software Verification Status Shows Promise Reason about real-life code Fully automatic No user-supplied assertions or induction hypotheses Still in Early Stages Can only deal with limited class of programs Memory referencing & aliasing possibilities difficult to decipher Look for particular classes of errors Property checking rather than comprehensive verification