Automating Hazard Checking in Transaction-Level Microarchitecture Models

Automating Hazard Checking in Transaction-Level

Microarchitecture Models

Automating Hazard Checking in Transaction-Level

Microarchitecture Models

Yogesh Mahajan, Sharad Malik

Princeton University

Yogesh Mahajan, Sharad Malik

Princeton University

FMCAD 2007, Austin

Outline

• Transaction level -architecture models

• Issues in model checking for hazards

• Case study & conclusion

April 21, 2023 FMCAD 2007, Austin 2

Outline





Background


RTL

• Wide gap between Spec and RTL• Structural RTL description loses higher

level functional description• Hard to determine verification tasks

• What to check?• Bridged largely by human effort

• Expensive, incomplete, error prone• Lowers adoption of formal methods

Fill gap through appropriate design model Transaction-level Microarchitecture

Modeling [Memocode ’07]

C, SystemVerilog,English, etc.

Specification

Transactions

Global State Elements

T

Resources (+ Arbiters)

read resources

resource requirements

write

resourcearbitration

FSM

M1

Transaction Level-Architecture


feature comment

Transaction Concurrent functional specification (data centric)

Global State Data container

Resource Concurrent hardware implementation

DataData

Start End


Reg AReg A

Reg BReg B

Reg CReg C

pcpc

read write


Regfile ports

• Pipelined processor

memmem

……

……

Decode logic

ALU


Instruction

F ExD W

Ld

St

• Multiple transactions instances in-flight

R

data stationary

time stationary

time stationary

Natural to state properties which involve

Transaction sequencing Temporal ordering• Transaction atomicity

Example: Hazards in pipelined transactions

Natural to state properties which involve

• Transaction sequencing• Temporal ordering• Transaction atomicity

TransactionsT


readresources

write

resourcearbitration

FSMs

M1M2





DataData

Model checking transaction level -architecture models?

Outline






T1

T2

T3

T4

M1 Execution : tt

t+1

time

t+2

t+3

t+4

t+5

t+6

DataData transaction instantiation order

futuretransaction instances


T1

T2

T3

T4

M1

• instance T1 created

Execution : t

T1

t

t+1

time

t+2

t+3

t+4

t+5

t+6

DataData transaction instantiation order

activetransaction

instance

T1

T2

T3

T4

11FMCAD 2007, AustinApril 21, 2023

M1 Execution : t +1


T1

t

t+1

time

t+2

t+3

t+4

t+5

t+6

T2

transaction instantiation orderDataData

T1

T2

T3

T4


M1 Execution : t +2


t

t+1

time

t+2

t+3

t+4

t+5

t+6

T3T1 T2


T1

T2

T3

T4


M1 Execution : t +3

• T2 stalls; no new

instance

t

t+1

time

t+2

t+3

t+4

t+5

t+6

T3T2T1


Execution : t +4

T1

T2

T3

T4


M1

• T1 retires; T4 created

t

t+1

time

t+2

t+3

t+4

t+5

t+6

T4T3T2

T1


retiredinstance

T1

T2

T3

T4


M1 Execution : t +5

• make progress…

t

t+1

time

t+2

t+3

t+4

t+5

t+6T4T3T2

T1


Execution : t +6

T1

T2

T3

T4


M

1

• T3 retires

t

t+1

time

t+2

t+3

t+4

t+5

t+6T4

T3

T2

T1


Issue 1: Unbounded State Space

• Unbounded #transaction instances

Resolution• #in-flight transaction instances is

bounded in practice, due to finite hardware resources

• Assume: #in-flight transactions ≤ k– Guarantee using model checking

• Enables use of a fixed set of state variables S1, S2, … Sk

– one per active transaction

• Dynamically reuse S1, S2, … Sk


T

T

T

T

M

T

2

T

DataData


T1

T2

T3

T4

M1


Execution : t

S1S1

S2S2

S3S3

DataData

T1

T2

T3

T4


M1 Execution : t +1


S1S1

S2S2

S3S3

DataData

T1

T2

T3

T4


M1 Execution : t +2


S1S1

S2S2

S3S3

DataData

T1

T2

T3

T4


M1 Execution : t +3


instance

S1S1

S2S2

S3S3

DataData

Execution : t +4

T1

T2

T3

T4


M1

• T1 ends; T4 created

S1S1

S2S2

S3S3

S1 gets reused

DataData

S1 gets freed

T1

T2

T3

T4


M1 Execution : t +5


S1S1

S2S2

S3S3

DataData

Execution : t +6

T1

T2

T3

T4


M1

• T3 ends

S1S1

S2S2

S3S3

DataData

Issue 2: Maintaining Transaction Ordering Information

• Recall: Interesting properties involve transaction sequencing as well temporal ordering

– Example: A Read-After-Write hazard depends on relative instantiation order of transactions

• Encoding must retain this ordering information• Resolution:

– Encoding that captures relative order of transaction



T1

T2

T3

T4

M1


Execution : t

S1S1

S2S2

S3S3

DataData

T1

T2

T3

T4


M1 Execution : t +1


S1S1

S2S2

S3S3

DataData

T1

T2

T3

T4


M1 Execution : t +2


S1S1

S2S2

S3S3

DataData

T1

T2

T3

T4


M1 Execution : t +3


instance

S1S1

S2S2

S3S3

DataData

Execution : t +4

T1

T2

T3

T4


M1

• T1 ends; T4 created

S1S1

S2S2

S3S3

DataData

Order-preserving encoding

S3 gets freedS1 gets freed

T1

T2

T3

T4


M1 Execution : t +5


S1S1

S2S2

S3S3

DataData

Execution : t +6

T1

T2

T3

T4


M1

• T3 ends

S1S1

S2S2

S3S3

Gap-free ordered encoding• Results in canonical form for symmetric configurations• Faster fixpoint convergence

DataData

RAW hazard detection


T1

t

t+1

time

t+2

t+3

t+4

t+5

t+6

T2

T3

T4

R

R

W

W

transaction instantiation order

• R – read from ‘s’

• W – write to ‘s’

• ‘s’ is a global state element

• 2 RAW hazards indicated

• Only T3 is active at t+6

• T4 has retired – its state is not

recorded in any of S1, S2, … Sk

• Only T3 is active at t+6

• T4 has retired – its state is not

recorded in any of S1, S2, … Sk



T1

t

t+1

time

t+2

t+3

t+4

t+5

t+6

T2

T3

T4

R

R

W

• T1 and T2 are both active at t+3• T1 and T2 are both active at t+3

Idea: Augment each S1, S2, … Sk with a bit which records if transaction has read ‘s’

?


W

Issue 3: Summarizing State of Retired Transactions

• Need to remember relevant information about retired transactions

Resolution

• Store a fixed size summary– Keep track of the youngest reader




t

t+1

time

t+2

t+3

t+4

t+5

t+6


T3

T4

R

W?

T5

• If a younger transaction instance makes a read, adequate to catch the RAW hazard involving the younger instanceR



t

t+1

time

t+2

t+3

t+4

t+5

t+6


T3

T4

R

W

T5

• If a younger transaction instance makes a read, adequate to catch the RAW hazard involving the younger instanceR



t

t+1

time

t+2

t+3

t+4

t+5

t+6


T3

T4

R

W?

T5

• When the youngest reader instance retires, mark the next youngest transaction in instantiation order as a reader



t

t+1

time

t+2

t+3

t+4

t+5

t+6


T3

T4

R

W

R

T5

• When the youngest reader instance retires, mark the next youngest transaction in instantiation order as a reader



t

t+1

time

t+2

t+3

t+4

t+5

t+6


T3

T4

R

W?

• If no younger instance is alive, keep the “ghost” of the retired youngest reader instance alive after it retires



t

t+1

time

t+2

t+3

t+4

t+5

t+6


T3

T4

R

W

• If no younger instance is alive, keep the “ghost” of the retired youngest reader instance alive after it retires



t

t+1

time

t+2

t+3

t+4

t+5

t+6


T3

T4

R

W?

T5

• When a “ghost” is present, the next transaction instance to be created is marked as a reader



t

t+1

time

t+2

t+3

t+4

t+5

t+6


T3

T4

R

W

T5

R

• When a “ghost” is present, the next transaction instance to be created is marked as a reader

Outline






Reg AReg A

Reg BReg B

Reg CReg Cread

write

Case Study

resources requiredSimple Pipeline

R 1 W

Mutex_A

Reg_mutexes

Mutex_B

Mutex_C2

• Handwritten Cadence SMV code to illustrate– Gap-free age sorted encoding– Summarizing Read-Status of deceased transaction

instances– Parameter k (#in-flight transaction instances)

• Time: 10s SMV time to verify absence of RAW hazards (Pentium IV, 512KB cache, 1 GB memory)– Buggy version without mutex gives counter-example in 1s

Mutex_DReg DReg D

Future Work

• Can we generalize the results presented here?– Wider range of properties involving temporal ordering

of events and data sequencing

– What sort of properties admit fixed size summaries?

– How do we specify these properties? • scope, syntax


Summary


Natural to state properties with Transaction sequencing Temporal ordering• Transaction atomicity

Issues in model checking hazards:• Unbounded #transactions• Order preserving encoding• Summarizing read-status

TransactionsT

read write


DataData


resourcesresource

arbitration FSMs

M

Could enable greater automation of common verification tasks

Documents

Automating Hazard Checking in Transaction-Level Microarchitecture Models