470 likes | 652 Views
Automating Hazard Checking in Transaction-Level Microarchitecture Models. Yogesh Mahajan , Sharad Malik Princeton University. Outline. Transaction level m -architecture models Issues in model checking for hazards Case study & conclusion. Outline. Transaction level m -architecture models
E N D
Automating Hazard Checking in Transaction-Level Microarchitecture Models YogeshMahajan, SharadMalik Princeton University FMCAD 2007, Austin
Outline • Transaction level m-architecture models • Issues in model checking for hazards • Case study & conclusion FMCAD 2007, Austin
Outline • Transaction level m-architecture models • Issues in model checking for hazards • Case study & conclusion 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 FMCAD 2007, Austin
T Transaction Level m-Architecture Resources (+ Arbiters) Transactions resource requirements M1 Start End resource arbitration FSM read write resources Global State Elements Data FMCAD 2007, Austin
Transaction Level m-Architecture St data stationary Ld Instruction Regfile ports resource requirements R 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 FMCAD 2007, Austin
T Transaction Level m-Architecture Resources (+ Arbiters) Transactions M2 resource requirements M1 resource arbitration FSMs resources read write • 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 Global State Elements Data Model checking transaction level m-architecture models? FMCAD 2007, Austin
Outline • Transaction level m-architecture models • Issues in model checking for hazards • Case study & conclusion FMCAD 2007, Austin
Execution: t Data M1 transaction instantiation order t T1 t+1 t+2 T2 future transaction instances t+3 T3 t+4 t+5 T4 t+6 time FMCAD 2007, Austin
Execution: t Data M1 transaction instantiation order t T1 T1 t+1 t+2 T2 active transaction instance t+3 T3 t+4 t+5 T4 t+6 • instance T1 created time FMCAD 2007, Austin
Execution: t +1 Data M1 transaction instantiation order t T1 t+1 T1 T2 t+2 T2 t+3 T3 t+4 t+5 T4 t+6 • instance T2 created time FMCAD 2007, Austin
Execution: t +2 Data M1 transaction instantiation order t T1 t+1 t+2 T2 T1 T2 T3 t+3 T3 t+4 t+5 T4 t+6 • instance T3 created time FMCAD 2007, Austin
Execution: t +3 Data M1 transaction instantiation order t T1 t+1 t+2 T2 t+3 T1 T2 T3 T3 t+4 t+5 T4 t+6 • T2 stalls; no new instance time FMCAD 2007, Austin
Execution: t +4 Data M1 transaction instantiation order t retired instance T1 t+1 t+2 T2 t+3 T1 T3 t+4 T2 T3 T4 t+5 T4 t+6 • T1 retires; T4 created time FMCAD 2007, Austin
Execution: t +5 Data M1 transaction instantiation order t T1 t+1 t+2 T2 t+3 T1 T3 t+4 t+5 T2 T4 T3 T4 t+6 • make progress… time FMCAD 2007, Austin
Execution: t +6 Data M1 transaction instantiation order t T1 t+1 t+2 T2 t+3 T1 T3 t+4 t+5 T4 T3 t+6 T2 T4 • T3 retires time FMCAD 2007, Austin
Issue 1: Unbounded State Space T • 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 FMCAD 2007, Austin
Execution: t Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T1 created FMCAD 2007, Austin
Execution: t +1 Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T2 created FMCAD 2007, Austin
Execution: t +2 Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T3 created FMCAD 2007, Austin
Execution: t +3 Data M1 T1 S1 T2 S2 S3 T3 T4 • T2 stalls; no new instance FMCAD 2007, Austin
Execution: t +4 Data M1 S1 gets freed S1 gets reused T1 S1 T2 S2 S3 T3 T4 • T1 ends; T4 created FMCAD 2007, Austin
Execution: t +5 Data M1 T1 S1 T2 S2 S3 T3 T4 • make progress… FMCAD 2007, Austin
Execution: t +6 Data M1 T1 S1 T2 S2 S3 T3 T4 • T3 ends 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 FMCAD 2007, Austin
Execution: t Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T1 created FMCAD 2007, Austin
Execution: t +1 Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T2 created FMCAD 2007, Austin
Execution: t +2 Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T3 created FMCAD 2007, Austin
Execution: t +3 Data M1 T1 S1 T2 S2 S3 T3 T4 • T2 stalls; no new instance FMCAD 2007, Austin
Execution: t +4 Data M1 S1 gets freed S3 gets freed T1 S1 T2 S2 S3 T3 T4 Order-preserving encoding • T1 ends; T4 created FMCAD 2007, Austin
Execution: t +5 Data M1 T1 S1 T2 S2 S3 T3 T4 • make progress… FMCAD 2007, Austin
Execution: t +6 Data M1 T1 S1 T2 S2 S3 T3 T4 • Gap-free ordered encoding • Results in canonical form for symmetric configurations • Faster fixpoint convergence • T3 ends FMCAD 2007, Austin
RAW hazard detection 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 FMCAD 2007, Austin
RAW hazard detection transaction instantiation order Idea: Augment each S1, S2, … Sk with a bit which records if transaction has read ‘s’ t 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 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 FMCAD 2007, Austin
RAW hazard detection 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 FMCAD 2007, Austin
RAW hazard detection 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 FMCAD 2007, Austin
RAW hazard detection 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 FMCAD 2007, Austin
RAW hazard detection 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 FMCAD 2007, Austin
RAW hazard detection 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 FMCAD 2007, Austin
RAW hazard detection 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 FMCAD 2007, Austin
RAW hazard detection 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 FMCAD 2007, Austin
RAW hazard detection 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 FMCAD 2007, Austin
Outline • Transaction level m-architecture models • Issues in model checking for hazards • Case study & conclusion FMCAD 2007, Austin
Case Study Simple Pipeline resources required Reg A write Reg B Mutex_C Mutex_D Mutex_B Mutex_A D1 R W D2 Reg C read Reg_mutexes Reg 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 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 FMCAD 2007, Austin
T Summary • Natural to state properties with • Transaction sequencing • Temporal ordering • Transaction atomicity Resources (+ Arbiters) M resource arbitration FSMs resources Transactions Could enable greater automation of common verification tasks read write • Issues in model checking hazards: • Unbounded #transactions • Order preserving encoding • Summarizing read-status Global State Elements Data FMCAD 2007, Austin