shuvendu k. lahiri sanjit a. seshia randal e. bryant carnegie mellon university, usa

Modeling and Verification of Modeling and Verification of Out-of-Order Out-of-Order

Microprocessors in UCLIDMicroprocessors in UCLID

Modeling and Verification of Modeling and Verification of Out-of-Order Out-of-Order

Microprocessors in UCLIDMicroprocessors in UCLID

Shuvendu K. LahiriShuvendu K. Lahiri

Sanjit A. SeshiaSanjit A. Seshia

Randal E. BryantRandal E. Bryant

Carnegie Mellon University, USACarnegie Mellon University, USA

FMCAD’02

Processor VerificationProcessor Verification

Views of System OperationViews 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 TaskVerification Task Prove all instruction sequences execute as predicted by instruction

set model

Instruction Set Architecture

Microarchitecture

Transition:One instructionexecution

Transition:One clock cycle

FMCAD’02

Introduction and Related WorkIntroduction and Related Work

Inorder Pipeline VerificationInorder 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 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

FMCAD’02

Out-Of-Order Processor VerificationOut-Of-Order Processor Verification

Theorem Proving approachesTheorem 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.]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 ApproachesOther Approaches Finite State Model Checking [Berezin et al.], Incremental Flushing

[Skakkaebek et al.], Decision Procedure [Velev]

FMCAD’02

ContributionsContributions

Extends the work by Bryant & VelevExtends the work by Bryant & Velev Restricted to Inorder pipelines with bounded resources

Application of UCLIDApplication of UCLID Modeling Framework for Out-Of-Order processors Application of three verification approaches to Out-Of-Order

Processor

Effective use of automated decision procedureEffective use of automated decision procedure For proving large formulas automatically Simple heuristics for quantifier instantiation

FMCAD’02

CLU : Logic of UCLIDCLU : Logic of UCLIDTerms (Terms (T T )) Integer Expressions

ITE(F, T1, T2) If-then-elseFun (T1, …, Tk) Function applicationsucc (T) Incrementpred (T) Decrement

Formulas (Formulas (F F )) Boolean ExpressionsF, F1 F2, F1 F2 Boolean connectives

T1 = T2 Equation

T1 < T2 Inequality

P(T1, …, Tk) Predicate application

Functions (Functions (FunFun)) Integers Integerf Uninterpreted function symbol x1, …, xk . T Function definition

Predicates (Predicates (PP)) Integers Booleanp Uninterpreted predicate symbolx1, …, xk . F Predicate definition

FMCAD’02

Decision ProcedureDecision Procedure

OperationOperation Series of

transformations leading to propositional formula

Propositional formula checked with BDD or SAT tools

Bryant, Lahiri, Seshia [CAV02]

LambdaExpansion

Function&

PredicateElimination

Convert to BooleanFormula

BooleanSatisfiability

CLUFormula

-freeFormula

Function-freeFormula

BooleanFormula

FMCAD’02

Modeling Memories with ’sModeling Memories with ’s

InitiallyInitially

Arbitrary stateModeled by uninterpreted function m0

Writing Transforms MemoryWriting Transforms Memory next[M] = Write(M, wa, wd)

a . ITE(a = wa, wd, M(a))

Future reads of address wa will get wd

Ma

M

a m0

next[M]

Ma 1

0

wd

=wa

Memory M Modeled as FunctionMemory M Modeled as Function

M(a): Value at location a

FMCAD’02

Modeling Unbounded FIFO BufferModeling Unbounded FIFO Buffer

Queue is Subrange of Infinite SequenceQueue is Subrange of Infinite Sequence h : INT

Head of the queue

t : INTTail of the queue

q : INT INTFunction mapping indices to valuesq(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)

•••

•••

tailtail

headhead

FMCAD’02

Modeling FIFO Buffer (cont.)Modeling FIFO Buffer (cont.)

tt

q(h–2)

q(h–1)

q(h)

q(h+1)

•••

q(t–2)

q(t–1)

q(t)

q(t+1)

•••

•••

hh

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[t]

next[hnext[h]]

op = PUSHInput = x

FMCAD’02

Modeling Parallel UpdatesModeling Parallel Updates

Simultaneous-Update MemoriesSimultaneous-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 BuffersUseful 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

FMCAD’02

UCLID descriptionUCLID description

Systems are modeled in CLU logicSystems are modeled in CLU logic

Three verification techniquesThree verification techniques Based on Symbolic Simulation Uses the decision procedure Counter example traces generated for verification failures

Bounded Property Checking

CorrespondenceChecking

Inductive InvariantChecking

Term-level Symbolic Simulator

Decision Procedure Counter ExampleGenerator

BDD SAT

FMCAD’02

Verification Techniques in UCLIDVerification Techniques in UCLID

Bounded Property CheckingBounded 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 Correspondence Checking Run 2 different simulations starting in most general state Prove that final states equivalent e.g. Burch-Dill Technique

Invariant CheckingInvariant Checking Start in general state s Prove Inv(s) Inv(next[s]) Limited support for automatic quantifier instantiation

FMCAD’02

An Out-of-order Processor (OOO)An Out-of-order Processor (OOO)

Out of order execution engineOut of order execution engine Register Renaming

Inorder retirementInorder retirement Unbounded Reorder buffer

Arithmetic instructions onlyArithmetic instructions only

Model different components in UCLIDModel different components in UCLID

Reorder BufferFields

PC

Programmemory

Reorder Buffer

validvaluesrc1validsrc1valsrc1tagsrc2validsrc2valsrc2tagdestop

result bus

DECODE Register

Rename Unit

valid tag val

ALU

head tail

incrdispatch

retire

execute

result

1st

Operand

2nd

Operand

FMCAD’02

Verification of OOO : Automation vs. GuaranteeVerification of OOO : Automation vs. Guarantee

Presence of decision procedurePresence of decision procedure Efficiency : Allows improved bounded property checking

and Burch-Dill method Automation : Reduces manual guidance in proving

invariants Automatic Instantiation of quantifiers

Method Resources Verification (# of steps)

Auxiliary variables

Invariants

Bounded Property Checking

Unbounded Bounded None None

Burch-Dill Technique

Fixed Unbounded None Very few

Inductive Invariant Checking

Unbounded Unbounded Significant Significant, including those for auxiliary variables

FMCAD’02

Technique 1 : Bounded Property CheckingTechnique 1 : Bounded Property CheckingDebugging OOO using Bounded Property CheckingDebugging OOO using Bounded Property Checking

All the errors were discovered during this phase Counterexample trace of great help

Debugging Motorola ELF™ Debugging Motorola ELF™ Superscalar out-of-order processor Reorder Buffer, memory unit, load-store queues etc. Applied during early design exploration phase

FMCAD’02

Bounded Property Checking ResultsBounded Property Checking Results

SVC (Stanford) : Another decision procedure to solve CLU formulas SVC (Stanford) : Another decision procedure to solve CLU formulas Can decide more expressive class

CVC (Successor of SVC) runs out of memory on larger casesCVC (Successor of SVC) runs out of memory on larger cases

ModelModel stepssteps termsterms Term Term formula formula sizesize

Prop Prop Formula Formula SizeSize

UCLID UCLID time (s)time (s)

SVC time SVC time (s)(s)

OOO unitOOO unit 10 59 2566 15290 10.8 233.18

14 87 7480 62504 76.55 > 5 hrs

20 129 19921 263413 1679.12 > 1 day

Elf™Elf™ 6 33 218 942 1.2 10.9

8 70 1085 4481 8.4 1851.6

10 104 2467 16453 30.6 > 1 day

12 149 4553 54288 111.0 > 1 day

FMCAD’02

Technique 2 : Burch-Dill TechniqueTechnique 2 : Burch-Dill Technique

Restrict the number of entries in the Reorder BufferRestrict 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 Qimpl

Critical for Out-of-Order processor verification Redundancy present in the OOO model

Because of out-of-order execution and register renaming

Qimpl Qimplimpl

Abs

Qspec Qspeckspec

Abs

k = issue width of OOO

impl = Transition function of OOO

spec = Transition function of ISA

Abs = Relates OOO state

with an ISA state

FMCAD’02

Technique 2 : Burch-Dill TechniqueTechnique 2 : Burch-Dill Technique

More automated than inductive invariant checkingMore 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

Qimpl Qimplimpl

Abs

Qspec Qspeckspec

Abs

k = issue width of OOO

impl = Transition function of OOO

spec = Transition function of ISA

Abs = Relates OOO state

with an ISA state

FMCAD’02

Burch-Dill Technique for OOOBurch-Dill Technique for OOO

Exponential blowup with the number of ROB entriesExponential blowup with the number of ROB entries Limited to r = 8 entries currently r = 8 finished after case-splitting in 2.5hrs

# Of ROB# Of ROB

EntriesEntries

# of # of termsterms

Term Term formula formula

sizesize

Prop Formula Prop Formula SizeSize

UCLID UCLID time (s)time (s)

2 63 398 5325 6.83

3 83 618 10248 30.23

4 103 886 18175 157.41

6 143 1534 41208 3051.79

8 183 2342 82915 >31hrs

FMCAD’02

Technique 3 : Invariant CheckingTechnique 3 : Invariant Checking

Deriving the inductive invariantsDeriving the inductive invariants Require additional (auxiliary) variables to express invariants Auxiliary variables do not affect system operation

Proving that the invariants are inductiveProving that the invariants are inductive Automate proof of invariants in UCLID Eliminates need for large (often fragile) proof script

FMCAD’02

Restricted Invariants and ProofsRestricted Invariants and Proofs

Restricted classes of invariantsRestricted classes of invariants x1x2…xk (x1…xk)

(x1…xk) is a CLU formula without quantifiers

x1…xk are integer variables free in (x1…xk)

Proving these invariants requires quantifiersProving these invariants requires quantifiers|= (x1x2…xk (x1…xk)) y1y2…ym (y1…ym)

Automatic instantiation of Automatic instantiation of x1…xk with concrete termswith concrete terms Sound but incomplete method

Reduce the quantified formula to a CLU formulaReduce the quantified formula to a CLU formula Can use the decision procedure for CLU

FMCAD’02

Shadow StructuresShadow Structures

Auxiliary variables Auxiliary variables Added to predict correct value of state variables 3 shadow variables for 3 state variables

rob.value : shdw.valuerob.src1val : shdw.src1valrob.src2val : shdw.src2val

Similar to McMillan’s approach and Arons et al.’s approach

FMCAD’02

Adding Shadow StructuresAdding Shadow Structures

shdw.src1val[rob.tail] shdw.src1val[rob.tail] RfRfisaisa(src1)(src1)

shdw.src2val[rob.tail] shdw.src2val[rob.tail] RfRfisaisa(src2)(src2)

shdw.value[rob.tail] shdw.value[rob.tail]

ALU(RfALU(Rfisaisa(src1), Rf(src1), Rfisaisa(src2), op)(src2), op)

shdw.value

shdw.src1val

shdw.src2val

Shadow Fields

Updated directly from theISA model during dispatch

result bus

ReorderBuffer Fields

PC

Programmemory

Reorder Buffer


DECODE Register

Rename Unit

valid tag val

ALU

head tail

incrdispatch

retire

execute

FMCAD’02


1.1. robrobt. rob.valid(t) t. rob.valid(t) rob.value(t) = shdw.value(t) rob.value(t) = shdw.value(t)

2.2. robrobt. rob.src1valid(t) t. rob.src1valid(t) rob.src1val(t) = shdw.src1val(t) rob.src1val(t) = shdw.src1val(t)

3.3. robrobt. rob.src2valid(t) t. rob.src2valid(t) rob.src2val(t) = shdw.src2val(t) rob.src2val(t) = shdw.src2val(t)

shdw.value

shdw.src1val

shdw.src2val

Shadow Fields

result bus


PC

Programmemory

Reorder Buffer


DECODE Register

Rename Unit

valid tag val

ALU

head tail

incrdispatch

retire

execute

FMCAD’02

Refinement MapsRefinement Maps

Correspondence with a sequential ISA modelCorrespondence with a sequential ISA model OOO and ISA synchronized at dispatch

For Register File ContentsFor Register File Contents r. reg.valid(r) reg.val(r) = Rfisa(r)

For Program CounterFor Program Counter PCooo = PCisa

shdw.value

shdw.src1val

shdw.src2val

Shadow Fields



PC

Programmemory

Reorder Buffer

result bus

DECODE

RegisterRename Unit

valid tag val

ALU

head tail

incr dispatch

retire

execute

FMCAD’02

Invariants Invariants

Tag Consistency invariants (2) Tag Consistency invariants (2) Instructions only depend on instruction preceding in

program order

Register Renaming invariants (2)Register Renaming invariants (2) Tag in a rename-unit should be in the ROB, and the

destination register should matchr.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 instructionrobt.(reg.valid(rob.dest(t))

t reg.tag(rob.dest(t)) < rob.tail)

FMCAD’02

Invariants (cont.)Invariants (cont.)

Executed instructions have operands readyExecuted instructions have operands readyrobt. rob.valid(t)

rob.src1valid(t) rob.src2valid(t)

Shadow-Value-Operands Relationship Shadow-Value-Operands Relationship robt. shdw.value(t) = Alu(shdw.src1val(t),shdw.src2val(t),rob.op(t))

Producer-Consumer Values (2)Producer-Consumer Values (2)robt. rob.src1valid(t)

shdw.src1val(t) = shdw.value(rob.src1tag(t))

Total 13 InvariantsTotal 13 Invariants Includes Refinement Maps Constraints on Shadow Variables

FMCAD’02

Proving InvariantsProving Invariants

Proved automaticallyProved 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 CVCNot possible to use SVC or CVC Ordering between integer array indices

robt. rob.src1valid(t) rob.src1tag(t) < t SVC/CVC interprets terms over reals (x < y+1) (x y)

Valid when x,y are integersInvalid when x,y are reals

FMCAD’02

Why Quantifier Instantiation worksWhy Quantifier Instantiation works

FMCAD’02

Extensions to the base modelExtensions to the base model

Increase concurrency of designIncrease 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 Scalar SuperscalarSuperscalar 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

FMCAD’02

Adding circular reorder bufferAdding circular reorder buffer

ROB modeled as a finite but arbitrary-size circular FIFOROB modeled as a finite but arbitrary-size circular FIFO Tags are reused No dispatch when the reorder buffer is full

Changes in the modelChanges 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 scriptChanges in proof script Add 1 invariant about the relationship of rob.present and

active elements of ROB

Again the proof of invariants automatic !!Again the proof of invariants automatic !!

FMCAD’02

Liveness ProofLiveness Proof

LivenessLiveness Every dispatched instruction is eventually retired

Assumes a “fair” schedulerAssumes a “fair” scheduler Attempts to execute the instruction at the head infinitely

often

Proceed by a high level inductionProceed 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

FMCAD’02

Current Status and Future WorkCurrent Status and Future Work

Use of decision procedure in deductive verificationUse 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 automaticallyNeed 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 modelsDetecting convergence of such term-level models Would enable automatic proof of models with finite buffers

QuestionsQuestions

FMCAD’02

Introduction and Related WorkIntroduction and Related Work

Microprocessor VerificationMicroprocessor 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

FMCAD’02

Exploiting Positive Equality Exploiting Positive Equality

Decision Procedure exploits “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 EqualityPositive 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

FMCAD’02

Instruction Set Architecture (ISA)Instruction Set Architecture (ISA)

FMCAD’02

UCLID descriptionUCLID description

FMCAD’02

Modeling Circular Queues Modeling Circular Queues

head tail

H0 T0

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

FMCAD’02

Term-level modelingTerm-level modeling

Abstract Bit-Vectors with Integers (Terms)Abstract Bit-Vectors with Integers (Terms) Allow restricted set of operations

x=y, x y, succ(x), pred(x)

““Black-box” certain combinational blocks Black-box” certain combinational blocks Replace by uninterpreted functions Maintain functional consistency

ALUf

FMCAD’02

Example : Motorola ELF™ ProcessorExample : Motorola ELF™ Processor

FeaturesFeatures 32-bit Dual issue with 64 GPRs 5 stage pipeline Out-of-order issue, in order completion of up to 2 instructions

Load/Store unitLoad/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 RTL1000 lines of UCLID model derived from 20K lines of RTL

FMCAD’02

Bounded Property CheckingBounded 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 ISA

impl impl impl impl impl impl

Impl state when 1 or 2instruction(s) complete

Impl state when no instruction(s) complete

ISA state

FMCAD’02

Quantifier InstantiationQuantifier Instantiation

ProveProve|= (x1x2…xk (x1…xk)) y1y2…ym (y1…ym)

1.1. Introduce Skolem Constants (Introduce Skolem Constants (y*y*1,…,y*y*mm))

|= (x1x2…xk (x1,…,xk)) (y*1,…,y*m)

2.2. Instantiate 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 Formula size grows exponentially with the number of bound variablesof bound variables

FMCAD’02

Updating Shadow StructuresUpdating Shadow Structures

During the During the dispatchdispatch of of newnew instruction instruction

I = I = <src1,src2,dest,op><src1,src2,dest,op>

next[shdw.value] := t. (t = rob.tail ?

Alu(Rfisa(src1),Rfisa(src2),op) :

shdw.value(t)); next[shdw.src1val] :=

t. (t = rob.tail ? Rfisa(src1) :

shdw.src1val(t)); next[shdw.src2val] :=

t. (t = rob.tail ? Rfisa(src2) :

shdw.src2val(t));

FMCAD’02




PC

Programmemory

Reorder Buffer

result bus

DECODE Register

Rename Unit

valid tag val

ALU

head tail

incrdispatch

retire

execute

PC

Programmemory

DECODE

incr

shdw.value

shdw.src1val

shdw.src2val

Shadow Fields

FMCAD’02

Refinement MapsRefinement Maps

For Register File ContentsFor Register File Contents r. reg.valid(r) reg.val(r) = Rfisa(r)

If a register is not being modified by any instruction in ROB, then the value matches the ISA value

For Program CounterFor Program Counter PCooo = PCisa

FMCAD’02

InvariantsInvariants


0

FMCAD’02

Burch-Dill TechniqueBurch-Dill Technique

More automated than inductive invariant checkingMore 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 QInvariants on initial state Qoooooo 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

FMCAD’02

Invariants Invariants

Total 13 invariants requiredTotal 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

robt.(reg.valid(rob.dest(t))

t reg.tag(rob.dest(t)) < rob.tail)

shuvendu k. lahiri sanjit a. seshia randal e. bryant carnegie mellon university, usa

Documents