Microarchitecture Verification by Compositional Model Checking Ken McMillan Ranjit Jhala Cadence Berkeley Labs / UC Berkeley

Microarchitecture VerificationMicroarchitecture Verificationbyby

Compositional Model Compositional Model CheckingCheckingKen McMillan Ranjit Jhala

Cadence Berkeley Labs / UC Berkeley

Microarchitectural Verification by Compositional Model Checking 2

Introduction

• Compositional Model Checking: – Decomposing large proofs to a set of automatically provable lemmas

• Previous Work:– Unbounded or infinite state systems: Flash, SGI, Bakery,…– Tomasulo’s Algorithm, with just 3 lemmas

• No need for manually constructed inductive invariant

• Q: Can the method scale to large and complex systems ?– Does the effort grow in reasonable proportion to the

complexity

• Verification of a complete processor microarchitecture– Incremental cost of each architectural feature is small– Very concise proofs


Plan

• Compositional Model Checking :– How to reduce the verification of unbounded systems

to a finite state problem

• Microarchitecture Modeled

• Important aspects of the proof

• Proof Decomposition : An example

• Comparison with other techniques


Proof Decomposition

• reduction to decidable/tractable problems• do it in as few (and as simple) steps as possible

Proof goal Undecidable/intractable

subDecidable/tractablesubsubsub


Functional Decompositions

• Possible decompositions of problem– Structural (by syntax)– Temporal (by time steps)– Functional (by “units of work”)

• Functional yields simple intermediate assertions– interaction between “units of work” is simpler than

between system components

• Reduction to finite state– each “unit of work” uses finite resources– identify resources used for a given case– abstract away everything else


Reduction to Finite State

property

model checking

decomposition “circular” temporal proof•divide into “units of work”

parameterization temporal “case splitting”•identify resources used

abstraction abstract interpretation•reduce to finite state


“Circular” Temporal Proofs

• Let p q stand for “if p up to time t-1, then q at t”

• Equivalent in LTL of:(p U q) : Not the case that q is the first to be false

• Now we can reason as follows:

That is, if neither p nor q is the first to befalse, then both are always true.

q pp q

Gp Gq


Using a Reference Model

Ref. Model

A

B

q p

q pp q

Gp Gq

e.g., programmer’s model

A and B each perform a “unit of work”

refinement relations(temporal properties)

“circular” proof:


Temporal Case Splitting

p1 p2 p3 p4 p5

v1

...

Idea:parameterize on mostrecent writer w attime t.

: I'm O.K. attime t.

i: G((w=i) )G


Combine With Circular Reasoning

p1 p2 p3 p4 p5

v1

...


To prove case w=i at time t, assume general case up to t-1:

i: ((w=i) )G


Abstract Interpretation

• Problem: variables range over unbounded set U• Solution: reduce U to finite set Û by a

parameterized abstraction, e.g.

where U\i represents all the values in U except i

• Need a sound abstract interpretation, such that:if is valid in the abstraction, then, for all parameter

valuations, is valid in the original

Û = {{i}, U\i}


Data Type Abstractions in SMV

• Examples:– Equality

– Function symbol application

= {i} U\i

{i}

U\i

1

0

0

^

^

x

f(x) f(i)

{i} U\i

Unbounded array reduced to one fixed element!

Note: truth value under abstraction may be

represents“no information”


Applying Abstraction

pi

v1

...


((w=i) )

abstractedelements

i.e, if pi is the most recent to modify v1, then v1

is correct.

Must verify by model checking:


Review

• By a sequence of three steps:1. “circular” temporal reasoning

(restricts to one “unit of work”)2. case splitting (adding parameters)

(identifies resources used in that unit of work)3. abstraction interpretation

(abstracts away everything else)

...we reduce the verification of an unbounded system of processes to a finite state problem.


Plan








Instruction Set Architecture (ISA)

The ISA we consider, supports the following instructions:• LOAD regsrc regdst

– regdst := Mem[regsrc]

• STORE regsrc regdst

– Mem[regdst] := regsrc

• ALU regsrca regsrcb regdst

– Regdst := F(regsrca, regsrcb)

• BRANCH regsrca regsrcb offset– Branch to target (function of pc, offset) based on F(regsrca, regsrcb) is

true

• JUMP regsrc

– Transfer control to regsrc

• OUT regsrc

– Send the data in regsrc to the Output Port

LOAD, STORE, ALU may raise exceptions


Salient Features

• Out of Order Execution– Tomasulo’s Algorithm – Reorder Buffer

• Speculative Execution– modelled by a non-deterministic Branch Predictor

• Precise Exceptions• Optimised Load/Store Buffer

– Reordering of Operations– Load Forwarding

• Unbounded– Memory, Register File, Reorder Buffer, LSB, Execution

Units


The Processor Model

ReorderBuffer

EU

RETIRED RESULTS / BUS

INSTRUCTIONSPM

PC

branchpredictor

dec

OP,DST

opra oprb EU

OPS

BUF

BUF

BUF

DataMemory

branch results

VAL/TAG

REGFILE

VAL/TAG

VAL/TAG

VAL/TAG

OP,DST

opra oprb

OP,DST

opra oprb

RES

LD/STBUFFER

data forwarding

EU


How it works: An instruction’s path

• Unit of work = instruction

ReorderBuffer

EU


INSTRUCTIONSPM

PC

branchpredictor

dec

OP,DST

opra oprb EU

OPS

BUF

BUF

BUF

DataMemory

branch results

VAL/TAG

REGFILE

VAL/TAG

VAL/TAG

VAL/TAG

OP,DST

opra oprb

OP,DST

opra oprb

RES

LD/STBUFFER

data forwarding

EU


Plan








IMPLEMENTATION

Refinement Maps

Stall / Shadow

What are we Proving ?

ISA MODEL


Proof Strategy

• Show the Implementation Refines the ISA model by writing and verifying refinement maps– Whenever there is an OUT instruction, the output of the

IMPL must be the same as that of the ISA

• For every instruction, the correct operands/results taken from ISA model and stored in auxiliary variables– Used to write refinement maps specifying the values

during different stages in the instruction’s lifetime– Shadowed instructions: Don’t care, as they do not change

state

• Secondary lemmas – Strengthen the abstraction : Non-interference etc.– Cut down the model size


Key Elements of the proof

• Writing the refinement maps

• Handling Speculation – Shadow bit marks every instr. that “should not” have been

executed– For such instructions, refinement maps don’t have to specify

values

• Handling data dependencies in Out-of-Order Execution– Tomasulo’s Algorithm: Implicitly data-flow – Load/Store Buffer


Proof : A Bird’s Eye View

Refinement Maps

Shadowed? Don’t Care


INSTRUCTIONSPM

PC

branchpredictor

dec

OP,DST opra oprb

EU

OPS

BUF

BUF

BUF

DataMemory

branch results

VAL/TAGREGFILE

VAL/TAG

VAL/TAGVAL/TAG

OP,DST opra oprb

OP,DST opra oprb

RES

LD/STBUFFER

data forwarding

EU

EU


ISA Instruction Stream

Fetch/Dec/Exc/WB in 1 cyc

Handling Speculation: Synchronizing

IMPL Instruction Stream

Fetch/Dec At the same time as ISA


Handling Speculation: Shadow Bit

Writeback

Shadowed !Stall

• ISA Stalls if IMPL guesses wrong,

• Enters “Shadow” State

• Subsequent IMPL instructions are “Shadowed”

• “Shadowed” status propagated

• Bad Instruction reaches WriteBack:• IMPL flushes unfinished instructions


Handling Speculation: Shadow Bit

• ISA Stalls if IMPL guesses wrong,

• Enters “Shadow” State

• Subsequent IMPL instructions are “Shadowed”

• “Shadowed” status propagated

• Bad Instruction reaches WriteBack:• IMPL flushes unfinished instructions

• ISA exits “Shadow” state, continues

• Subsequent IMPL instructions are clean


Should be

last writer

Handling Data Dependencies

ISA Time

IMPL TimeRead

Corresp. ISA

Instr.

Read

Write

Corresp. IMPL

Instr.

Write

Corresp. Write

Write

Actual

last writer

• All other instructions abstracted away

• Model Checking fails ! Abstraction too coarse …• A different (abstracted) instruction is the actual last writer in Counter-Ex !

• Put both instructions in the abstraction• Or show separately that they are the same


Should be

last writer

Handling Data Dependencies

ISA Time

IMPL TimeRead

Corresp. ISA

Instr.

Read

Write

Corresp. IMPL

Instr.

Write

Corresp. Write

Write

Actual

last writer

• The “time” step of an instr. is the time it was issued

• For unshadowed instructions:

• ISA and IMPL issue “corresponding” instructions synchronously

• Easy to track correspondences


Plan








”Unit of Work” Decomposition

Unlocked Registers Have Correct Data

Instructions ReceiveCorrect Operands

InstructionsProduce Correct

Results


• Split Cases on:1. Register2. The last instruction that should have written to that register

(ISA)– But what if some bogus (abstracted) instruction wrote to it

?3. The last instruction that actually wrote to that register (IMPL)

• Both are stored as auxiliary variables • Model Checking should show the two are the same …• … and also as that instruction produced the correct result

(from refinement map), that the register has Correct Data

Unlocked Registers have Correct Data 1

tShould Actual



…But Speculation Causes Problems: • The instruction with the bad guess is abstracted away, thus there is no flushing …

• …A shadowed instruction writes to the register!

Fails To Flush !

Wrongly Flushes !

• An Intermediate (abstracted) instruction wrongly flushes the valid unshadowed instruction …

• … The register has stale data !

Can solve by splitting cases on flushing instr but …

3 instructions ) State Explosion !



Lemmas to deal with speculation: Problem: Shadowed Inst. Writes Back

Lemma: Every instruction writing back is not shadowed

Split Cases on:

1) Instruction causing shadow

2) Instruction writing backFails To Flush !

Wrongly Flushes !

Problem: Unshadowed Inst. Flushed !

Lemma: When there is a flush, there is no Unshadowed inst. in buffer

Split Cases on:

1) Instruction causing the flush

2) Unshadowed instruction


• Need to prove: Every LOAD returns the correct value • Split Cases on:

1. Address 2. Last STORE instruction that should have written to that address

(ISA)3. Last STORE instruction that actually wrote to that address (IMPL)

• Aux. Variables, Model Checking should show they are the same

• Data forwarding and Reordering for free !

Load Store Buffer

Should

Actual

LOADSTORESTORE


• Problem: Need to model resources of 3 instructions– Case and State Explosion !

• Avoid modelling all resources by writing a refinement map for LSB– Use ISA, aux vars to specify the contents of valid entries in the

buffer– Abstract away everything except the LSB and the Memory

• Break into 2 simpler lemmas– Each requires splitting cases on 2 instructions

Load Store Buffer

Should

Actual

LOADSTORESTORE


Plan








Comparison With Other Techniques

• Sawada & Hunt, Velev & Bryant, Hosabettu et. al.

• Variants of Burch-Dill “Flushing” Technique– Abstraction function not strong enough to be invariant

– Manually constructed invariants needed– Reason about entire machine state, intractable– Decomposing the “flushing” function – advantage of BD lost !

Init IMPL State

Abstract

IMP0

Abstract

IMP1

Next IMPL State

ISA1 ISA0 ISA Step

IMPL Step


Comparison With Other Techniques

• Velev & Bryant– Efficiently checking commutativity condition– No Out-of-Order or LSB : Flushing functions too complex ?

• Sawada & Hunt – Track status of instructions using a MAETT – similar to our aux. Vars– Need a huge inductive invariant

• Hosabettu et al.– Completion functions

Proof Sizes:• Sawada & Hunt: ACL2, Spec: 60 Kb, Proof: 1909 Kb, Lemmas:

4000• Hosabettu et al.: PVS , Spec: 70 Kb, Proof: 2300 Kb• CMC : SMV , Spec: 20 Kb, Proof: 18 Kb, Lemmas:

18


Conclusions

• How to use CMC to verify microarchitectures with several modern features

• Proof strategies to handle speculation, rd/wr reordering

• Succintness of proof:– No need for invariants– Functional Decomposition into “units of work”

• Proof methodology scales well :– Would be easy to add features like caches, multiple issue, etc.

• CMC to verify a “real” microarchitecture• Show how a model written at a high level can be

refined to an RTL implementation• Use Cadence SMV !

Documents

Microarchitecture Verification by Compositional Model Checking Ken McMillan Ranjit Jhala Cadence Berkeley Labs / UC Berkeley