1. Proof of Correctness of a Processor with Reorder Buffer using the Completion Functions Approach Ravi Hosabettu (Univ. of Utah) Mandayam Srivas (SRI International) Ganesh Gopalakrishnan (Univ. of Utah)

2. 2 Motivation Pipelined processor verification –Increasingly complex designs –Need for formal verification Theorem provers –Focus on the relevant aspects only To verify large, complex designs: –Automation –Decomposition

3. 3 Problem Definition Need a verification methodology that –Is amenable to decomposition –Uses decision procedures Solution: Completion Functions Approach

4. 4 What are Completion Functions? Desired effect of retiring an unfinished instruction in an atomic fashion ab c RF C_b

5. 5 Abstraction Function Need to define an abstraction function Flushing the pipeline Our idea: Define abstraction function as a Composition of Completion Functions Impl. Machine Step Spec. Machine Step

6. 6 Main Features Decomposition into verification conditions Generated systematically & discharged often automatically RF ab c C_bC_aC_c L_ab Abs. fn = C_a o C_b o C_c One VC is: C_a == L_ab o C_b

7. 7 Main Features Continued Incremental verification No explicit intermediate abstraction Methodology implemented in PVS Three examples (CAV98) –DLX –Dual issue DLX –Out-of-order execution example

8. 8 New Issues for OOO ab c RF DB RTT RB RF EU

9. 9 Completion Functions Approach for OOO Instructions in a few possible states –Parameterized completion function Recursive abstraction function Proof decomposition is based on “instruction-state transitions” Liveness issues addressed

10. 10 Outline of the Presentation The implementation model Proof of correctness –Correctness criterion –Liveness proof Related work and conclusions

11. 11 Processor Model RF RTT RB EU1EUm DB

12. 12 Proof of Correctness Specifying the completion function Correctness criterion & abstraction function Decomposing the proof –“Instruction-state transition” diagram –Discharging the verification conditions Correctness of the feedback logic Invariants needed

13. 13 The Completion Function RF RB EU1 DB rbi Action_issued Action_dispatched Action_executed Action_writtenback

14. 14 Correctness Criterion Abstraction I_step A_step/  impl_st

15. 15 Recursive Abstraction Function RB tailhead rbi RF Abs. fn = Complete_till(head)

16. 16 General Verification Condition I D W W D E E W I I D E q next(q) RF Same

17. 17 Instruction-state Transitions IEW Disp? Not Disp? Exec? Not Exec? Wback? Not Wback?Not Retire? Retire? D

18. 18 Establishing the General Verification Condition I D W W D E E W I I D E q next(q) Action_executed Same effect on RF Action_dispatched

19. 19 Overall Proof Decomposition IEW D RF N ISA specification

20. 20 Decomposition Summary Decomposes into ten obligations –Certain invariants needed –Correctness of the feedback logic Case analysis strategy in simplifying

21. 21 Feedback Logic Feedback logic correctness: A = B 12i Feedback logic RF C_1 C_2 Read A B

22. 22 Invariants Needed Feedback logic invariant Exclusiveness & exhaustiveness Instruction-state properties

23. 23 PVS Proof Statistics Proof strategies –Induction obligations: Very similar strategy –Rewrite rules & other obligations: Automatic –Invariants: No uniform strategy Manual effort –1 week of planning & discussions –12 person days of “first time” effort 1050 seconds on 167MHz UltraSparc

24. 24 Liveness Properties Two liveness properties –Eventually the processor gets flushed –Eventually a new instruction is executed Again based on “Instruction-state transition” diagram

25. 25 Liveness Proof IDEW Disp? Not Disp? Exec? Not Exec? Wback? Not Wback?Not Retire? Retire? Scheduler

26. 26 Related Work Jones, Skakkebaek & Dill - FMCAD98 Pnueli & Arons - FMCAD98 Sawada & Hunt - CAV98 McMillan - CAV98

27. 27 Conclusions Well suited for verifying a processor with reorder buffer Proved the correctness of Tomasulo’s algorithm with no reorder buffer: CHARME99

28. 28 Work in Progress A processor with exceptions & speculative execution –Substantial progress made Mechanizing the liveness proofs Bring the methodology closer to practice –Bridging the model gap –More automated decision procedures –Integration into the design process