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

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

Problem Definition

• Need a verification methodology that

– Is amenable to decomposition

– Uses decision procedures

• Solution: Completion Functions Approach

4

What are Completion Functions?

• Desired effect of retiring an unfinished instruction in an atomic fashion

a b c

RFC_b

5

Abstraction Function

• Need to define an abstraction function

• Flushing the pipeline

• Our idea: Define abstraction function as a Composition of Completion Functions

Impl.MachineStep

Spec.MachineStep

6

Main Features

• Decomposition into verification conditions

• Generated systematically & discharged often automatically

RF

a b c

C_bC_a C_c

L_ab

Abs. fn = C_a o C_b o C_cOne VC is: C_a == L_ab o C_b

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

New Issues for OOO

a b c

RF

DB

RTT

RB

RF

EU

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

Outline of the Presentation

• The implementation model

• Proof of correctness– Correctness criterion– Liveness proof

• Related work and conclusions

11

Processor Model

RF

RTT RB

EU1 EUmDB

13

The Completion Function

RF

RB

EU1DB

rbi

Action_issued

Action_dispatched

Action_executed

Action_writtenback

14

Correctness Criterion

AbstractionAbstraction

I_step

A_step/

impl_st

15

Recursive Abstraction Function

RB

tailhead

rbi

RF

Abs. fn = Complete_till(head)

16

General Verification Condition

I

D

W

W

D

E

E

W

I

I

D

E

q

next(q)

RF

RF

Same

17

Instruction-state Transitions

I E WDisp?

Not Disp?

Exec?

Not Exec?

Wback?

Not Wback? Not Retire?

Retire?D

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

Overall Proof Decomposition

I E WD

RF

N

ISA specification

21

Feedback Logic

• Feedback logic correctness: A = B

12i

Feedback logic

RFC_1C_2

Read

A

B

22

Invariants Needed

• Feedback logic invariant

• Exclusiveness & exhaustiveness

• Instruction-state properties

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

Liveness Properties

• Two liveness properties– Eventually the processor gets flushed– Eventually a new instruction is executed

• Again based on “Instruction-state transition” diagram

25

Liveness Proof

I D E WDisp?

Not Disp?

Exec?

Not Exec?

Wback?

Not Wback? Not Retire?

Retire?

Scheduler

26

Related Work

• Jones, Skakkebaek & Dill - FMCAD98

• Pnueli & Arons - FMCAD98

• Sawada & Hunt - CAV98

• McMillan - CAV98

27

Conclusions

• Well suited for verifying a processor with reorder buffer

• Proved the correctness of Tomasulo’s algorithm with no reorder buffer: CHARME99

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