1 / 47

Automating Hazard Checking in Transaction-Level Microarchitecture Models

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

bertha
Download Presentation

Automating Hazard Checking in Transaction-Level Microarchitecture Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automating Hazard Checking in Transaction-Level Microarchitecture Models YogeshMahajan, SharadMalik Princeton University FMCAD 2007, Austin

  2. Outline • Transaction level m-architecture models • Issues in model checking for hazards • Case study & conclusion FMCAD 2007, Austin

  3. Outline • Transaction level m-architecture models • Issues in model checking for hazards • Case study & conclusion FMCAD 2007, Austin

  4. 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

  5. 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

  6. 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

  7. 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

  8. Outline • Transaction level m-architecture models • Issues in model checking for hazards • Case study & conclusion FMCAD 2007, Austin

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. Execution: t Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T1 created FMCAD 2007, Austin

  19. Execution: t +1 Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T2 created FMCAD 2007, Austin

  20. Execution: t +2 Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T3 created FMCAD 2007, Austin

  21. Execution: t +3 Data M1 T1 S1 T2 S2 S3 T3 T4 • T2 stalls; no new instance FMCAD 2007, Austin

  22. 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

  23. Execution: t +5 Data M1 T1 S1 T2 S2 S3 T3 T4 • make progress… FMCAD 2007, Austin

  24. Execution: t +6 Data M1 T1 S1 T2 S2 S3 T3 T4 • T3 ends FMCAD 2007, Austin

  25. 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

  26. Execution: t Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T1 created FMCAD 2007, Austin

  27. Execution: t +1 Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T2 created FMCAD 2007, Austin

  28. Execution: t +2 Data M1 T1 S1 T2 S2 S3 T3 T4 • instance T3 created FMCAD 2007, Austin

  29. Execution: t +3 Data M1 T1 S1 T2 S2 S3 T3 T4 • T2 stalls; no new instance FMCAD 2007, Austin

  30. 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

  31. Execution: t +5 Data M1 T1 S1 T2 S2 S3 T3 T4 • make progress… FMCAD 2007, Austin

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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

  38. 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

  39. 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

  40. 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

  41. 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

  42. 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

  43. 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

  44. Outline • Transaction level m-architecture models • Issues in model checking for hazards • Case study & conclusion FMCAD 2007, Austin

  45. 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

  46. 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

  47. 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

More Related