Deductive Verification of Out-of-Order Microprocessors

1. Deductive Verification of Advanced Out-of-Order Microprocessors Shuvendu K. Lahiri Randal E. Bryant Carnegie Mellon University

2. D E C O D E src1 valid value src1valid src1val src1tag src2valid src2val src2tag dest type pc target predict src2 P C dest imm epc type Memory Unit head tail Branch Unit Arithmetic Unit Mem lsq stq OOO Processor Model Register Rename Unit PC Unit Instruction Mem Branch Predictor Result Bus Reorder Buffer

3. Complexity of Out-of-Order Processor Verification • Unbounded Data • Integer data paths • Parameterized Computation • Uninterpreted functions and predicates • ALU, ExceptionRaise?, Decoding Logic • Unbounded Data structures • Memory • Ordered Data structures • Highly concurrent • Retire, execute, dispatch happen concurrently • Proving Sequential Semantics • With respect to an Instruction Set Architecture (ISA)

4. Related Work • Deductive Methods • Theorem prover based • Hosabettu et al. and Sawada et al. • Large proof scripts • Manual intervention to discharge the proofs • Uses “flushing” technique • Compositional Model Checking based • McMillan et al. • Does not apply to deep or superscalar processors • Exploits symmetry in the design • User decomposes the proof • Does not need auxiliary invariants

5. Earlier Work • Lahiri, Seshia and Bryant FMCAD’02 • Modeling and Verification of Out-of-Order Processors • Simple Out-of-order execution unit • Only arithmetic instructions • All proof obligations handled by decision procedure for UCLID

6. This work • Apply earlier work to more complex designs • Handle speculation and exceptions • Memory instructions, store forwarding etc. • Superscalar out-of-order processors • Can we model the new components in UCLID? • Load store queues, exceptions • Is refinement based deductive verification feasible ? • Earlier deductive methods use Burch-Dill technique • Recursive “flushing” function • Aarons & Pnueli use “refinement” for simpler models • Can we retain the automation of proofs ? • Relieve the user from interactively proving theorems

7. FIFO Insert when dispatch Remove when retire Content Addressable Broadcast result to all entries with matching source tag Retire Dispatch result bus ALU execute head tail • Directly Addressable • Select particular entry for execution • Retrieve result value from executed instruction Access Modes for Reorder Buffer • Global • Flush all queue entries when instruction at head causes exception

8. CLU : Logic of UCLID • 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 < T2 Inequality P(T1, …, Tk) Predicate application • Functions (Fun) Integers  Integer f Uninterpreted function symbol  x1, …, xk . T Function definition • Predicates (P) Integers  Boolean p Uninterpreted predicate symbol  x1, …, xk . F Predicate definition

9. Memory M Modeled as Function M(a): Value at location a Initially Arbitrary state Modeled by uninterpreted function m0 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 wa = M wd a m0 M a 1 0 Modeling Memories with ’s

10. Simultaneous-Update Memories Update arbitrary subset of entries at the same step Useful for modeling Reorder Buffer Forwarding data to all dependant instructions M(i) P(i+1) is true • • • • • • M(i+1) P(i+2) is true M(i+2) • • • M(j) P(j+1) is true M(j+1) next[M] :=i. ITE(P(i), D(i), M(i)) If entry i satisfies a predicate P(i) it is updated with D(i) M(j+2) P(j+3) is true M(j+3) Modeling Parallel Updates

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

12. • • • • • • Modeling Unbounded FIFO Buffer Already Popped • 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 = h0, Q.tail = t0 • Impose constraint that h0 t0 • Q.val = q0 • Uninterpreted function q(h–2) q(h–1) head q(h) q(h+1) • • • increasing indices q(t–2) q(t–1) tail q(t) q(t+1) Not Yet Inserted

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

14. Modeling Components of Processors • Reorder Buffer • FIFO • Instructions in Program Order • Parallel Update memory • Update from an executed instruction • Content Addressable • Load-Store Queue • FIFO • Store Queue • FIFO • Associative lookup by content • Find the latest entry containing an address • Flush part of the queue • Do not flush retired instructions

15. Verification Approach • Extending the approach in FMCAD’02 • Worked with a simple OOO execution unit • No speculation or memory • Deductive verification

16. p is proved Deductive Verification • d is the state transition relation, • F describes the initial states • p is the property to be proved, • jis an inductive invariant, which implies p Prove F j Prove jd j’ Prove j p

17. Restricted Invariants and Proofs • Invariants of the form x1x2…xk (x1…xk) • (x1…xk) is a CLU formula without quantifiers • x1…xk are integer variables free in (x1…xk) • Proving these invariants requires quantifiers |= (x1x2…xk (x1…xk))  y1y2…ym (y1…ym) • Automatic instantiation of x1…xk with concrete terms • Sound but incomplete method • Reduce the quantified formula to a CLU formula • Can use the decision procedure for CLU

18. Proving correctness • Refinement Maps • Establish relation between OOO and sequential ISA model • A refinement map for each ISA visible state element • Register File • Program Counter • Data Memory • Example • “If a register is not being modified in OOO, then it should have the same value as in the ISA”

19. Description of Verification

20. Auxiliary Data Structures • Shadow Fields • “Predicts” correct value for OOO state elements • Updated during DISPATCH by ISA machine • Auxiliary Fields • Need to define a consistent internal state of OOO • Does not depend on ISA machine • Usually additional maps

21. ISA Reg. File PC Adding Shadow State • McMillan, ‘98 • Arons & Pnueli, ‘99 • Provides Link Between ISA & OOO Models • Additional entries in ROB • Do not affect OOO behavior • Generated when instruction dispatched • Predict values of operands and result • From ISA model OOO Reg. File PC Reorder Buffer

22. Shadow States • Operands and Result of an instruction • Correct values • Shadow Register Rename Unit • Latest non-speculative instruction to modify a register • Shadow Memory Address Map • Latest non-speculative instruction to modify a memory address

23. Auxiliary Structures • Restricted Invariant Structure • x1x2…xk (x1…xk) • Adding complicated Invariants • For every non-executed memory instruction I in ROB, there exists an entry in the Load-Store Queue (LSQ) • Requires Existential () Properties • Add auxiliary structure as witness for  • Add a map - rob_lsq_ptr : ROB  LSQ • For every non-executed memory instruction I in ROB, rob_lsq_ptr (I) is present in LSQ

24. Restricted Invariant Structure x1x2…xk (x1…xk) Adding Complicated Invariants For every non-executed memory instruction I in ROB, there exists an entry in the Load-Store Queue (LSQ) Requires Existential () Properties Auxiliary Structures Add auxiliary structure as witness for  • Add a map - rob_lsq_ptr : ROB  LSQ • For every non-executed memory instruction I in ROB, rob_lsq_ptr (I) is present in LSQ

25. Auxiliary Structures • rob_lsq_ptr : ROB  LSQ • lsq_rob_ptr : LSQ  ROB already part of the model • rob_stq_ptr : ROB  STQ, stq_rob_ptr : STQ  ROB • Need reverse maps • ld_stq_ptr : ROB  STQ • For each Load instruction, the STQ entry that would forward data

26. Incremental Models • Basic Out-of-order execution unit (base) • Reorder Buffer, Register Rename Unit • Exception Handling (exc) • Arithmetic exceptions • Branch Prediction (exc/br) • Memory Instruction – Simple (exc/br/mem-simp) • Stores commit during RETIRE • Illegal Address exceptions • Memory Instruction (exc/br/mem) • Stores commit sometime after RETIRE

27. t ROB. t reg.tag(rob.dest(t)) Counterexamples • Strengthen Invariants • Use counter-examples to (manually) strengthen the invariants • Example Invariant : t ROB. reg.valid(rob.dest(t)) • Is the invariant inductive ? • Is it preserved by the transition function ? • Counterexample • rob.hd = 1, rob.tl = 10 • rob.valid[1] = true • t = 5 • rob.dest[5] = r10 • reg.tag[r10] = 1 • reg.valid[r10] = false • operation = retire

28. Misspeculation Invariants • Predict the instruction that would cause misspeculation • Result of branch misprediction or exception • Shadow entry to keep track of this instruction • shdw_exn_mpred_tag : tag in the ROB • Gets updated from ISA machine during DISPATCH • Reset during a “flush” of the OOO state • Invariants • Earliest misspeculated instruction • Instruction at shdw_exn_mpred_tag should raise an exception or be mispredicted • Others

29. Ordering Invariants • Maintain Program Order in different data structures • Reorder Buffer • Load Store Queue • Store Queue • Often the source of complicated invariants • For memory instructions I1, I2 • Instruction I1 precedes I2 in Reorder Buffer iff I1 precedes I2 in Load-Store Queue • If instruction I1 depends on instruction I2, then I1 precedes I2 in program order

30. Load-Store Invariants • Correct Value of a Load (r,A) • If A present in STQ • Value from STQ • If shdw.mem_tag(A) in ROB and A not in STQ • Value of the store • Else • Value from the memory

31. Shadow Invariants • Relate Shadow Variables to State Variables • t ROB. [rob.valid(t)  rob.value(t) = shdw.value(t)] • t ROB. [rob.src1valid(t)  rob.src1val(t) = shdw.src1val(t) ] • t ROB. [rob.src2valid(t)  rob.src2val(t) = shdw.src2val(t) ]

32. Comparative Verification Effort • Proof script size substantially smaller • 67KB as opposed to 1909 KB (Hosabettu et al.) • Very little user intervention in discharging proofs • Instantiation of quantifiers • Mostly automatic, few manual for larger examples

33. Going Superscalar • Superscalar • Dispatch 0… d instructions at each step • Retire 0… r instructions at each step • Complex Control Logic • Additional forwarding in DISPATCH window • Additional forwarding in RETIRE window • Extended the base model

34. Statistics for Superscalar Models • Does not require any change to proof script • Complicates control logic but the invariants still hold • Scales well with increasing width • Almost linear with the (Dispatch*Retire) width • Instantiation considers terms in (Dispatch + Retire) window

35. Conclusion • Case study of complex processors in UCLID • CLU expressive enough to model advanced features • Reasonable automation in discharging proofs • Use of automatic decision procedures • Quantification strategy robust • Need to generate invariants • Using Predicate Abstraction • Automatically constructed invariant for OOO-base model given the predicates • Improve desirability for deductive methods

36. H0 T0 head tail 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 = T0 : H0 ; default : succ(x); esac; next[content] := Lambda i. case (operation = PUSH) & (i = tail) : D ; default : content(i); esac Modeling Circular Queues

37. Address Data • • • • • • A(h–2) d(h–2) A(h–1) d(h–1) A(h) d(h) h retired A(h+1) d(h+1) • • r A(r) d(r) • • speculative A(t–2) d(t–2) A(t–1) d(t–1) t A(t) d(t) A(t+1) d(t+1) • • • • • • • • • Store Queue • Content Addressable • Look for an address • Same address at multiple index Latest Match • Latest index that matches address Partial Flush • Remove entries after an index

38. Address Data • • • • • • A(h–2) d(h–2) A(h–1) d(h–1) A(h) d(h) h retired A(h+1) d(h+1) • • r A(r) d(r) • • speculative A(t–2) d(t–2) A(t–1) d(t–1) t A(t) d(t) A(t+1) d(t+1) • • • • • • • • • Store Queue • Content Addressable • Look for an address • Same address at multiple index A1 A2 A3 • •

39. Quantifier Instantiation • Prove |= (x1x2…xk (x1…xk))  y1y2…ym (y1…ym) • Introduce Skolem Constants (y*1,…,y*m) |= (x1x2…xk (x1,…,xk))  (y*1,…,y*m) • Instantiate x1,…,xk with concrete terms • Assume single-arity functions and predicates • Let Fx = {f | f(x) is a sub-expression of (x1…xk)} • Let Tf = {t| f(t) is a sub-expression of (y*1…y*m)} • For each bound variable x, Ax = {t|f  Fx and t  Tf} • Instantiate  over Axi x Ax2 ...x Axk • Formula size grows exponentially with the number of bound variables