1. Modeling and Verification of Out-of-Order Microprocessors in UCLID Shuvendu K. Lahiri Sanjit A. Seshia Randal E. Bryant Carnegie Mellon University, USA

2. FMCAD’02 Processor Verification Views of System Operation Instruction Set Instructions executed in sequential order Instruction modifies “programmer-visible” state Microarchitecture At any given time, multiple instructions “in flight” State held in hidden pipeline registers and buffers Verification Task Prove all instruction sequences execute as predicted by instruction set model Instruction Set Architecture Microarchitecture Transition: One instruction execution Transition: One clock cycle

3. FMCAD’02 Introduction and Related Work Inorder Pipeline Verification Burch and Dill, CAV ’94 Relates implementation and specification by completing partially-executed instructions in the pipeline (flushing) Infinite data words, memories Bounded (fixed) resources only Can’t model a reorder buffer (ROB) of arbitrary length Out-of-Order Processor Verification Arbitrary large (64-128) reorder buffer, reservation stations and load-store queues Very large number of instruction in the pipeline No finite flushing function to drain the pipeline

4. FMCAD’02 Out-Of-Order Processor Verification Theorem Proving approaches Hosabettu et al. (‘00), Sawada et al.(98), Arons et al.(‘00) Write inductive invariants Manually guide the theorem-provers for proving invariants Large, complicated proof scripts (fragile) Seldom have good counterexample facilities Compositional Model Checking [McMillan et al.] Use compositional model checking with temporal case splitting, path splitting, symmetry and data-type reduction Does not need to write inductive invariants User needs to manually decompose the proof Has not been demonstrated effective for deep, superscalar pipelines Other Approaches Finite State Model Checking [Berezin et al.], Incremental Flushing [Skakkaebek et al.], Decision Procedure [Velev]

5. FMCAD’02 Contributions Extends the work by Bryant & Velev Restricted to Inorder pipelines with bounded resources Application of UCLID Modeling Framework for Out-Of-Order processors Application of three verification approaches to Out-Of-Order Processor Effective use of automated decision procedure For proving large formulas automatically Simple heuristics for quantifier instantiation

6. FMCAD’02 CLU : Logic of UCLID Terms ( T ) Terms ( T )Integer Expressions ITE(F, T 1, T 2 ) If-then-else Fun (T 1, …, T k ) Function application succ (T) Increment pred (T) Decrement Formulas ( F ) Formulas ( F )Boolean Expressions  F, F 1  F 2, F 1  F 2 Boolean connectives T 1 = T 2 Equation T 1 < T 2 Inequality P(T 1, …, T k ) Predicate application Functions ( Fun ) Functions ( Fun )Integers  Integer f Uninterpreted function symbol x 1, …, x k. T Function definition Predicates ( P ) Predicates ( P )Integers  Boolean p Uninterpreted predicate symbol  x 1, …, x k. F Predicate definition

7. FMCAD’02 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

8. FMCAD’02 Modeling Memories with ’s Initially Arbitrary state Modeled by uninterpreted function m 0 Writing Transforms Memory next[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 next [M] M a 1010 wd = wa Memory M Modeled as Function M(a): Value at location a

9. FMCAD’02 Modeling Unbounded FIFO Buffer Queue is Subrange of Infinite Sequence h : INT Head of the queue t : INT Tail of the queue q : INT  INT Function mapping indices to values q(i) valid only when h  i < t q(h–2) q(h–1) q(h) q(h+1) q(t–2) q(t–1) q(t) q(t+1) tail head

10. FMCAD’02 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] := case (operation = POP) : succ(h) ; default : h ; esac next[q] := lambda (i). case (operation = PUSH) & (i=t) : x; default : q(i) ; esac next[t] := case (operation = PUSH) : succ(t) ; default : t; esac 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

11. FMCAD’02 Modeling Parallel Updates Simultaneous-Update Memories Update arbitrary subset of entries at the same step next[M] := i. ITE(P(i), D(i), M(i)) Any entry, i, which satisfies a predicate P(i) will get updated with D(i) Useful for modeling Reorder Buffers Forwarding data to all dependant instructions M(i) D(i+2) D(i+1) M(j) D(j+1) M(j+2) D(j+3) P(i+1) is true P(i+2) is true P(j+1) is true P(j+3) is true M(i) M(i+2) M(i+1) M(j) M(j+1) M(j+2) M(j+3) P(i+1) is true P(i+2) is true P(j+1) is true P(j+3) is true

12. FMCAD’02 UCLID description Systems are modeled in CLU logic Three verification techniques Based on Symbolic Simulation Uses the decision procedure Counter example traces generated for verification failures Bounded Property Checking Correspondence Checking Inductive Invariant Checking Term-level Symbolic Simulator Decision ProcedureCounter Example Generator BDD SAT

13. FMCAD’02 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

14. FMCAD’02 An Out-of-order Processor (OOO) Out of order execution engine Register Renaming Inorder retirement Unbounded Reorder buffer Arithmetic instructions only Model different components in UCLID 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

15. FMCAD’02 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

16. FMCAD’02 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

17. FMCAD’02 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

18. FMCAD’02 Technique 2 : Burch-Dill Technique Restrict the number of entries in the Reorder Buffer The number of ROB entry = r Flushing as the abstraction function Flushing as the abstraction function Abs Alternate between executing the instruction at the head of the reorder buffer and retiring the head Inductive Invariants required for the initial state Inductive Invariants required for the initial state Q impl Critical for Out-of-Order processor verification Redundancy present in the OOO model Because of out-of-order execution and register renaming Q impl  impl Abs Q spec  k spec Abs k = issue width of OOO  impl = Transition function of OOO  spec = Transition function of ISA Abs = Relates OOO state with an ISA state

19. FMCAD’02 Technique 2 : Burch-Dill Technique More automated than inductive invariant checking Does not require auxiliary structures, Far fewer invariants than invariant checking Only 4 invariants compared to about 12 for inductive invariant checking approach Q impl  impl Abs Q spec  k spec Abs k = issue width of OOO  impl = Transition function of OOO  spec = Transition function of ISA Abs = Relates OOO state with an ISA state

20. FMCAD’02 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

21. FMCAD’02 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

22. FMCAD’02 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 ) 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

23. FMCAD’02 Shadow Structures Auxiliary variables Added to predict correct value of state variables 3 shadow variables for 3 state variables rob.value : shdw.value rob.src1val : shdw.src1val rob.src2val : shdw.src2val Similar to McMillan’s approach and Arons et al.’s approach

24. FMCAD’02 Adding Shadow Structures shdw.src1val[rob.tail] Rf isa (src1) shdw.src1val[rob.tail]  Rf isa (src1) shdw.src2val[rob.tail] Rf isa (src2) shdw.src2val[rob.tail]  Rf isa (src2) shdw.value[rob.tail] shdw.value[rob.tail]  ALU(Rf isa (src1), Rf isa (src2), op) shdw.value shdw.src1val shdw.src2val Shadow Fields Updated directly from the ISA model during dispatch result bus Reorder Buffer Fields PC Program memory Reorder Buffer valid value src1valid src1val src1tag src2valid src2val src2tag dest op DECODEDECODE Register Rename Unit valid tag val ALU headtail incr dispatch retire execute

25. FMCAD’02 Adding Shadow Structures 1.  rob t. rob.valid(t)  rob.value(t) = shdw.value(t) 2.  rob t. rob.src1valid(t)  rob.src1val(t) = shdw.src1val(t) 3.  rob t. rob.src2valid(t)  rob.src2val(t) = shdw.src2val(t) shdw.value shdw.src1val shdw.src2val Shadow Fields result bus Reorder Buffer Fields PC Program memory Reorder Buffer valid value src1valid src1val src1tag src2valid src2val src2tag dest op DECODEDECODE Register Rename Unit valid tag val ALU headtail incr dispatch retire execute

26. FMCAD’02 Refinement Maps Correspondence with a sequential ISA model OOO and ISA synchronized at dispatch For Register File Contents  r. reg.valid(r)  reg.val(r) = Rf isa (r) For Program Counter PC ooo = PC isa shdw.value shdw.src1val shdw.src2val Shadow Fields valid value src1valid src1val src1tag src2valid src2val src2tag dest op Reorder Buffer Fields PC Program memory Reorder Buffer result bus DECODEDECODE Register Rename Unit valid tag val ALU headtail incr dispatch retire execute

27. FMCAD’02 Invariants Tag Consistency invariants (2) Instructions only depend on instruction preceding in program order Register Renaming invariants (2) Tag in a rename-unit should be in the ROB, and the destination register should match  r.  reg.valid(r)  ( rob.head  reg.tag(r) < rob.tail  rob.dest(reg.tag(r)) = r ) For any entry, the destination should have reg.valid as false and tag should contain this or later instruction  rob t.(  reg.valid(rob.dest(t))  t  reg.tag(rob.dest(t)) < rob.tail)

28. FMCAD’02 Invariants (cont.) Executed instructions have operands ready  rob t. rob.valid(t)  rob.src1valid(t)  rob.src2valid(t) Shadow-Value-Operands Relationship  rob t. shdw.value(t) = Alu(shdw.src1val(t),shdw.src2val(t),rob.op(t)) Producer-Consumer Values (2)  rob t.  rob.src1valid(t)  shdw.src1val(t) = shdw.value(rob.src1tag(t)) Total 13 Invariants Includes Refinement Maps Constraints on Shadow Variables

29. FMCAD’02 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 Not possible to use SVC or CVC Ordering between integer array indices  rob t.  rob.src1valid(t)  rob.src1tag(t) < t SVC/CVC interprets terms over reals (x < y+1)  (x  y) Valid when x,y are integers Invalid when x,y are reals

30. FMCAD’02 Why Quantifier Instantiation works

31. FMCAD’02 Extensions to the base model Increase concurrency of design Infinite number of execution units Any subset of {dispatch,execute,retire,nop} can be active The same invariants were proved inductive without any changes Scalar Superscalar Scalar  Superscalar Incorporate issue width = 2 and retire width = 2 Data forwarding logic of the processor gets complicated Same set of invariants proved automatically No change in the proof script !! Runtime increased from 54s to 134s

32. FMCAD’02 Adding circular reorder buffer ROB modeled as a finite but arbitrary-size circular FIFO Tags are reused No dispatch when the reorder buffer is full Changes in the model Add a predicate rob.present() to indicate a rob entry contains valid entry Change the dispatch logic to stall when ROB full Modify ‘<’ to incorporate wrap-around Changes in proof script Add 1 invariant about the relationship of rob.present and active elements of ROB Again the proof of invariants automatic !!

33. FMCAD’02 Liveness Proof Liveness Every dispatched instruction is eventually retired Assumes a “fair” scheduler Attempts to execute the instruction at the head infinitely often Proceed by a high level induction Not mechanical Similar to Hosabettu [CAV98] approach Most lemmas required are already proved during safety proof (in UCLID) Concise proof

34. FMCAD’02 Current Status and Future Work Use of decision procedure in deductive verification Automate proof of invariants in micro-architecture verification with speculation, memory instructions [CMU-TR] Automate proof of invariants in verification of a directory based cache coherence protocol with unbounded clients and unbounded channels Need ways to generate (some) invariants automatically Pnueli et al.’s invisible invariant method [CAV01] Difficult to handle unbounded data, uninterpreted functions and ordering Detecting convergence of such term-level models Would enable automatic proof of models with finite buffers

35. Questions

36. FMCAD’02 Introduction and Related Work Microprocessor Verification Finite state symbolic Model Checking, Berezin et al. Compositional Model Checking, McMillan et al. Symbolic Simulation + Decision Procedure based, Burch & Dill, Bryant & Velev Theorem Proving Techniques, Sawada & Hunt, Hosabettu et al., Arons & Pnueli

37. FMCAD’02 Outline UCLID TOOL Logic and Decision Procedure Modeling Framework Verification Frameworks Out-Of-Order Processor Description Bounded Property Checking Results Burch-Dill Verification Results Invariant Checking Framework Shadow Structures Inductive Invariant Checking and Quantifiers Invariants Required Extension of the simple processor model

38. FMCAD’02 Exploiting Positive Equality Decision Procedure exploits “positive-equality” Bryant, German, Velev, CAV’99 Extended in presence of succ, pred operations Bryant, Lahiri, Seshia CAV’02 Positive Equality  Number of interpretations can be greatly reduced  Equations appearing only under even # of negations assigned false  Except when restricted by functional consistency  Terms compared in these equations get distinct interpretations --- called p-terms  Identifying p-terms is a pre-processing step

39. FMCAD’02 Instruction Set Architecture (ISA)

40. FMCAD’02 Symbols 

41. FMCAD’02 UCLID description

42. FMCAD’02 Modeling Circular Queues head tail H0H0 T0T0 next[head] := case (operation = POP) : succ’(head) ; default : head ; esac next[tail] := case (operation = PUSH) : succ’(tail) ; default : tail; esac succ’ := Lambda (x). case x = T 0 : H 0 ; default : succ(x); esac; next[content] := Lambda i. case (operation = PUSH) & (i = tail) : D ; default : content(i); esac

43. FMCAD’02 Term-level modeling Abstract Bit-Vectors with Integers (Terms) Allow restricted set of operations x=y, x  y, succ(x), pred(x) “Black-box” certain combinational blocks Replace by uninterpreted functions Maintain functional consistency ALUALU f

44. FMCAD’02 Example : Motorola ELF™ Processor Features 32-bit Dual issue with 64 GPRs 5 stage pipeline Out-of-order issue, in order completion of up to 2 instructions Load/Store unit 3-cycle load latency Fully pipelined Load queue for loads that miss in cache Store queue for retiring store instruction Other buffers to hide cache miss latency 1000 lines of UCLID model derived from 20K lines of RTL

45. FMCAD’02 Bounded Property Checking Compare the micro-architecture with a sequential ISA model w.r.t. Register File, Memory and PC ISA model synchronized at completion  ISA  impl Impl state when 1 or 2 instruction(s) complete Impl state when no instruction(s) complete ISA state

46. FMCAD’02 Quantifier Instantiation Prove |= (  x 1  x 2 …  x k  (x 1 …x k ))   y 1  y 2 …  y m  (y 1 …y m )  Introduce Skolem Constants ( y*y* m )  Introduce Skolem Constants ( y* 1,…,y* m ) |= (  x 1  x 2 …  x k  (x 1,…,x k ))   (y* 1,…,y* m )  Instantiate  Instantiate x 1,…,x k with concrete terms Assume single-arity functions and predicates Let F x = {f | f(x) is a sub-expression of  (x 1 …x k )} Let T f = {t | f(t) is a sub-expression of  (y* 1 …y* m )} For each bound variable x, A x = {t|  f  F x and t  T f } Instantiate  over A xi x A x2... x A xk Formula size grows exponentially with the number of bound variables Formula size grows exponentially with the number of bound variables

47. FMCAD’02 Updating Shadow Structures During the dispatch of new instruction I = I = next[shdw.value] := t. (t = rob.tail ? Alu(Rf isa (src1),Rf isa (src2),op) : shdw.value(t)); next[shdw.src1val] := t. (t = rob.tail ? Rf isa (src1) : shdw.src1val(t)); next[shdw.src2val] := t. (t = rob.tail ? Rf isa (src2) : shdw.src2val(t));

48. FMCAD’02 Adding Shadow Structures valid value src1valid src1val src1tag src2valid src2val src2tag dest op Reorder Buffer Fields PC Program memory Reorder Buffer result bus DECODEDECODE Register Rename Unit valid tag val ALU headtail incr dispatch retire execute PC Program memory DECODEDECODE incr shdw.value shdw.src1val shdw.src2val Shadow Fields

49. FMCAD’02 Refinement Maps For Register File Contents  r. reg.valid(r)  reg.val(r) = Rf isa (r) If a register is not being modified by any instruction in ROB, then the value matches the ISA value For Program Counter PC ooo = PC isa

50. FMCAD’02 Invariants valid value src1valid src1val src1tag src2valid src2val src2tag dest op 0

51. FMCAD’02 Burch-Dill Technique More automated than inductive invariant checking Does not require auxiliary structures, Far fewer invariants than invariant checking Only 4 invariants compared to about 12 for inductive invariant checking approach Invariants on initial state Q ooo Instructions only depend on instruction preceding in program order Tag in a rename-unit should be in the ROB, and the destination register should match For any entry, the destination should have reg.valid as false and tag should contain this or later instruction rob.head  rob.tail  rob.head + r

52. FMCAD’02 Invariants Total 13 invariants required Refinement map for RF and PC (2) Shadow structure constraints (3) Tag Consistency invariants (2) Instructions only depend on instruction preceding in program order Circular Register Renaming invariants (2) Tag in a rename-unit should be in the ROB, and the destination register should match  r.  reg.valid(r)  ( rob.head  reg.tag(r) < rob.tail  rob.dest(reg.tag(r)) = r ) For any entry, the destination should have reg.valid as false and tag should contain this or later instruction  rob t.(  reg.valid(rob.dest(t))  t  reg.tag(rob.dest(t)) < rob.tail)