Yogesh Mahajan, Sharad Malik Princeton University

Yogesh Mahajan, Sharad Malik Princeton University
Automating Hazard Checking in Transaction-Level Microarchitecture Models Yogesh Mahajan, Sharad Malik Princeton University There has been increasing interest in recent times in transaction level design and modeling. In hardware, a formal transaction level model at the microarchitecture level can help to increase the levels of automation in verification. In this talk, I will illustrate this for the case of checking hazards in such models. FMCAD 2007, Austin

Outline Transaction level m-architecture models
Issues in model checking for hazards Case study & conclusion September 19, 2018 FMCAD 2007, Austin

Background Specification 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. RTL September 19, 2018 FMCAD 2007, Austin

Transaction Level m-Architecture
Transactions Resources (+ Arbiters) T M1 resource requirements Start End resource arbitration FSM read write resources Global State Elements feature comment Transaction Concurrent functional specification (data centric) Global State Data container Resource Concurrent hardware implementation A transaction level microarchitecture marries high level concepts such as data transactions and lower level hardware concepts such as resource limitations. The model consists of 3 components –transactions, state elements and resources. A transaction is a finite state machine describing a well-defined unit computation on data – for example, executing an instruction in a processor or processing a frame in an image processing algorithm. Each transaction FSM has clearly marked START and END states. The Start state is colored GREEN and the end state colored RED. The data on which a transaction operates resides in global shared state elements. Each state is labeled with a set of resources needed for the execution of that state. The resources can have arbitration FSMs associated with them. The transactions describe the concurrency at the functional spec level, while resources describe concurrency at the hardware level. Data September 19, 2018 FMCAD 2007, Austin

St data stationary Ld Instruction Regfile ports R resource requirements F D Ex W Decode logic ALU read write time stationary mem pc Reg A … Multiple transactions instances in-flight Reg B time stationary … Reg C Pipelined processor September 19, 2018 FMCAD 2007, Austin

Transactions Resources (+ Arbiters) T M2 M1 resource requirements resource arbitration FSMs resources read write Natural to state properties which involve Transaction sequencing Temporal ordering Transaction atomicity Natural to state properties which involve Transaction sequencing Temporal ordering Transaction atomicity Example: Hazards in pipelined transactions Global State Elements Data Model checking transaction level m-architecture models? September 19, 2018 FMCAD 2007, Austin

transaction instances
Execution : t M1 Data transaction instantiation order t T1 t+1 T2 t+2 future transaction instances t+3 T3 t+4 t+5 T4 t+6 time September 19, 2018 FMCAD 2007, Austin

Execution : t T1 instance T1 created M1 Data
transaction instantiation order t T1 T1 t+1 T2 t+2 active transaction instance t+3 T3 t+4 t+5 T4 t+6 instance T1 created time September 19, 2018 FMCAD 2007, Austin

Execution : t +1 T1 T2 instance T2 created M1 Data
transaction instantiation order t T1 t+1 T1 T2 T2 t+2 t+3 T3 t+4 t+5 T4 t+6 instance T2 created time September 19, 2018 FMCAD 2007, Austin

Execution : t +2 T1 T2 T3 instance T3 created M1 Data
transaction instantiation order t T1 t+1 T2 t+2 T1 T2 T3 t+3 T3 t+4 t+5 T4 t+6 instance T3 created time September 19, 2018 FMCAD 2007, Austin

T2 stalls; no new instance
Execution : t +3 M1 Data transaction instantiation order t T1 t+1 T2 t+2 t+3 T1 T2 T3 T3 t+4 t+5 T4 t+6 T2 stalls; no new instance time September 19, 2018 FMCAD 2007, Austin

Execution : t +4 T1 T2 T3 T4 T1 retires; T4 created M1 Data
transaction instantiation order t retired instance T1 t+1 T2 t+2 t+3 T1 T3 t+4 T2 T3 T4 t+5 T4 t+6 T1 retires; T4 created time September 19, 2018 FMCAD 2007, Austin

Execution : t +5 T1 T2 T3 T4 make progress… M1 Data
transaction instantiation order t T1 t+1 T2 t+2 t+3 T1 T3 t+4 t+5 T4 T2 T3 T4 t+6 make progress… time September 19, 2018 FMCAD 2007, Austin

Execution : t +6 T1 T3 T2 T4 T3 retires M1 Data
transaction instantiation order t T1 t+1 T2 t+2 t+3 T1 T3 t+4 T3 finishes before T4 t+5 T4 T3 t+6 T2 T4 T3 retires time September 19, 2018 FMCAD 2007, Austin

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 M T Data T T T2 T  September 19, 2018 FMCAD 2007, Austin

Execution : t instance T1 created M1 Data T1 S1 T2 S2 S3 T3 T4
September 19, 2018 FMCAD 2007, Austin

Execution : t +1 instance T2 created M1 Data T1 S1 T2 S2 S3 T3 T4

Execution : t +3 M1 Data T1 S1 T2 S2 S3 T3 T4 T2 stalls; no new instance September 19, 2018 FMCAD 2007, Austin

Execution : t +4 T1 ends; T4 created M1 Data S1 gets reused
S1 gets freed T1 S1 T2 S2 S3 T3 S1 gets freed when T1 retires. The new instance T4 can now use the variables S1 T4 T1 ends; T4 created September 19, 2018 FMCAD 2007, Austin

Execution : t +5 make progress… M1 Data T1 S1 T2 S2 S3 T3 T4

Execution : t +6 T3 ends M1 Data T1 S1 T2 S2 S3 T3 T4
just by looking at S1, S2, S3 I cannot determine the instantiation order of the the transactions T2 and T4. T4 T3 ends September 19, 2018 FMCAD 2007, Austin

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 September 19, 2018 FMCAD 2007, Austin

Execution : t instance T1 created M1 Data T1 S1 T2 S2 S3 T3 T4

Execution : t +3 M1 Data T1 S1 T2 S2 S3 T3 T4 T2 stalls; no new instance September 19, 2018 FMCAD 2007, Austin

Execution : t +4 T1 ends; T4 created Order-preserving encoding M1 Data
S1 gets freed S3 gets freed T1 S1 T2 S2 S3 T3 Point out how the order of T1, T2, T3 is maintained by the mapping T4 Order-preserving encoding T1 ends; T4 created September 19, 2018 FMCAD 2007, Austin

Execution : t +5 make progress… M1 Data T1 S1 T2 S2 S3 T3 T4

Execution : t +6 T3 ends Gap-free ordered encoding
M1 Data T1 S1 T2 S2 S3 T3 T4 Gap-free ordered encoding Results in canonical form for symmetric configurations Faster fixpoint convergence T3 ends September 19, 2018 FMCAD 2007, Austin

RAW hazard detection T1 T2 T4 T3 R – read from ‘s’ W – write to ‘s’
transaction instantiation order t R t+1 R – read from ‘s’ W – write to ‘s’ ‘s’ is a global state element 2 RAW hazards indicated W t+2 R t+3 T1 t+4 T2 T4 t+5 W t+6 T3 time September 19, 2018 FMCAD 2007, Austin

RAW hazard detection T1 T2 T4 ? T3 T1 and T2 are both active at t+3
transaction instantiation order t Idea: Augment each S1, S2, … Sk with a bit which records if transaction has read ‘s’ R t+1 W t+2 T1 and T2 are both active at t+3 R t+3 T1 t+4 T2 T4 Only T3 is active at t+6 T4 has retired – its state is not recorded in any of S1, S2, … Sk t+5 W ? t+6 T3 time September 19, 2018 FMCAD 2007, Austin

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 September 19, 2018 FMCAD 2007, Austin

RAW hazard detection T4 ? T3 T5
transaction instantiation order t t+1 If a younger transaction instance makes a read, adequate to catch the RAW hazard involving the younger instance R t+2 t+3 T4 R t+4 W ? t+5 t+6 T3 T5 time September 19, 2018 FMCAD 2007, Austin

RAW hazard detection T4 T3 T5
transaction instantiation order t t+1 If a younger transaction instance makes a read, adequate to catch the RAW hazard involving the younger instance R t+2 t+3 T4 R t+4 W t+5 t+6 T3 T5 time September 19, 2018 FMCAD 2007, Austin

transaction instantiation order t t+1 When the youngest reader instance retires, mark the next youngest transaction in instantiation order as a reader R t+2 t+3 T4 t+4 W ? t+5 t+6 T3 T5 time September 19, 2018 FMCAD 2007, Austin

transaction instantiation order t t+1 When the youngest reader instance retires, mark the next youngest transaction in instantiation order as a reader R t+2 R t+3 T4 t+4 W t+5 t+6 T3 T5 time September 19, 2018 FMCAD 2007, Austin

RAW hazard detection T4 ? T3
transaction instantiation order t t+1 If no younger instance is alive, keep the “ghost” of the retired youngest reader instance alive after it retires R t+2 t+3 T4 t+4 W ? t+5 t+6 T3 time September 19, 2018 FMCAD 2007, Austin

RAW hazard detection T4 T3
transaction instantiation order t t+1 If no younger instance is alive, keep the “ghost” of the retired youngest reader instance alive after it retires R t+2 t+3 T4 t+4 W t+5 t+6 T3 time September 19, 2018 FMCAD 2007, Austin

transaction instantiation order t t+1 When a “ghost” is present, the next transaction instance to be created is marked as a reader R t+2 t+3 T4 t+4 W ? t+5 t+6 T3 T5 time September 19, 2018 FMCAD 2007, Austin

transaction instantiation order t t+1 When a “ghost” is present, the next transaction instance to be created is marked as a reader R t+2 t+3 T4 R t+4 W t+5 t+6 T3 T5 time September 19, 2018 FMCAD 2007, Austin

Case Study Handwritten Cadence SMV code to illustrate
Mutex_A Mutex_B Simple Pipeline resources required Reg A write Reg B Mutex_C Reg C R D1 W D2 read Reg D Reg_mutexes Mutex_D 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 September 19, 2018 FMCAD 2007, Austin

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 September 19, 2018 FMCAD 2007, Austin

Summary Resources (+ Arbiters) Natural to state properties with
arbitration FSMs M Natural to state properties with Transaction sequencing Temporal ordering Transaction atomicity Transactions Could enable greater automation of common verification tasks T read write Issues in model checking hazards: Unbounded #transactions Order preserving encoding Summarizing read-status Global State Elements Data September 19, 2018 FMCAD 2007, Austin

Yogesh Mahajan, Sharad Malik Princeton University

Similar presentations

Presentation on theme: "Yogesh Mahajan, Sharad Malik Princeton University"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Yogesh Mahajan, Sharad Malik Princeton University

Similar presentations

Presentation on theme: "Yogesh Mahajan, Sharad Malik Princeton University"— Presentation transcript:

Similar presentations

About project

Feedback