RTLCheck: Verifying the Memory Consistency of RTL Designs
|
|
|
- Alvin Blair
- 5 years ago
- Views:
Transcription
1 RTLCheck: Verifying the Memory Consistency of RTL Designs Yatin A. Manerkar, Daniel Lustig*, Margaret Martonosi, and Michael Pellauer* Princeton University *NVIDIA MICRO-50
2 Memory Consistency Models (MCMs) are Complex MCMs specify ordering requirements of memory operations in parallel programs Essential to correct parallel systems Difficult to specify and verify! Core 0 Core 1 Data = 100; Flag = 1; While (Flag!= 1) {} int r1 = Data; (All locations initially have a value of 0)
3 Memory Consistency Models (MCMs) are Complex MCMs specify ordering requirements of memory operations in parallel programs Essential to correct parallel systems Difficult to specify and verify! Core 0 Core 1 Data = 100; Flag = 1; While (Flag!= 1) {} int r1 = Data; (All locations initially have a value of 0)
4 Memory Consistency Models (MCMs) are Complex MCMs specify ordering requirements of memory operations in parallel programs Essential to correct parallel systems Difficult to specify and verify! Core 0 Core 1 Flag = 1; Data = 100; While (Flag!= 1) {} int r1 = Data; (All locations initially have a value of 0)
5 How to Verify Hardware MCM Behaviour? Hardware enforces consistency model using smaller localized orderings In-order fetch/wb Coherence protocol orderings and many more Fetch Dec. Exec. SB Lds. SB Fetch Dec. Exec. Mem. L1 L1 Mem. WB L2 WB Coherence Protocol (SWMR, DVI, etc.)
6 How to Verify Hardware MCM Behaviour? Hardware enforces consistency model using smaller localized orderings In-order fetch/wb Coherence protocol orderings and many more Fetch Dec. Exec. SB Lds. SB Fetch Dec. Exec. Mem. L1 L1 Mem. WB L2 WB Coherence Protocol (SWMR, DVI, etc.)
7 How to Verify Hardware MCM Behaviour? Hardware enforces consistency model using smaller localized orderings In-order fetch/wb Coherence protocol orderings and many more Fetch Dec. Exec. Mem. WB SB L1 Lds. L2 L1 SB Fetch Dec. Exec. Mem. WB FIFO store buffers help ensure Total Store Order (TSO) Coherence Protocol (SWMR, DVI, etc.)
8 How to Verify Hardware MCM Behaviour? Hardware enforces consistency model using smaller localized orderings In-order fetch/wb Coherence protocol orderings and many more Do individual orderings correctly work together Fetch Fetch Dec. Lds. Dec. to satisfy SB consistency SB model? Exec. Exec. Mem. L1 L1 Mem. WB L2 WB FIFO store buffers help ensure Total Store Order (TSO) Coherence Protocol (SWMR, DVI, etc.)
9 Our Prior Work: Microarchitectural Consistency Verification Microarchitecture in µspec DSL Axiom StoreBuffer_is_in_order":... EdgeExists ((i1, SB_Enter), (i2, SB_Enter)) => AddEdge ((i1, SB_Exit), (i2, SB_Exit)). Axiom "PO_Fetch":... SameCore i1 i2 /\ ProgramOrder i1 i2 => AddEdge ((i1, Fetch), (i2, Fetch)). Litmus Test
10 Our Prior Work: Microarchitectural Consistency Verification Microarchitecture in µspec DSL Axiom StoreBuffer_is_in_order":... EdgeExists ((i1, SB_Enter), (i2, SB_Enter)) => AddEdge ((i1, SB_Exit), (i2, SB_Exit)). Axiom "PO_Fetch":... SameCore i1 i2 /\ ProgramOrder i1 i2 => AddEdge ((i1, Fetch), (i2, Fetch)). Each axiom specifies an ordering that µarch Litmus should Test respect
11 Our Prior Work: Microarchitectural Consistency Verification Microarchitecture in µspec DSL Axiom StoreBuffer_is_in_order":... EdgeExists ((i1, SB_Enter), (i2, SB_Enter)) => AddEdge ((i1, SB_Exit), (i2, SB_Exit)). Axiom "PO_Fetch":... SameCore i1 i2 /\ ProgramOrder i1 i2 => AddEdge ((i1, Fetch), (i2, Fetch)). Litmus Test
12 Our Prior Work: Microarchitectural Consistency Verification Microarchitecture in µspec DSL Axiom StoreBuffer_is_in_order":... EdgeExists ((i1, SB_Enter), (i2, SB_Enter)) => AddEdge ((i1, SB_Exit), (i2, SB_Exit)). Axiom "PO_Fetch":... SameCore i1 i2 /\ ProgramOrder i1 i2 => AddEdge ((i1, Fetch), (i2, Fetch)). Litmus Test Microarchitectural happens-before (µhb) graphs
13 Our Prior Work: Microarchitectural Consistency Verification Microarchitecture in µspec DSL Axiom StoreBuffer_is_in_order":... EdgeExists ((i1, SB_Enter), (i2, SB_Enter)) => AddEdge ((i1, SB_Exit), (i2, SB_Exit)). Axiom "PO_Fetch":... SameCore i1 i2 /\ ProgramOrder i1 i2 => AddEdge ((i1, Fetch), (i2, Fetch)). [ Litmus Test Microarch. verification checks that combination of axioms satisfies MCM Microarchitectural happens-before (µhb) graphs
14 Our Prior Work: Microarchitectural Consistency Verification Microarchitecture Axiom StoreBuffer_is_in_order":... EdgeExists ((i1, SB_Enter), (i2, SB_Enter)) => AddEdge ((i1, SB_Exit), (i2, SB_Exit)). Axiom "PO_Fetch":... SameCore i1 i2 /\ ProgramOrder i1 i2 => AddEdge ((i1, Fetch), (i2, Fetch)). Litmus Test in µspec DSL [ Higher-level verif. requires maintaining ordering axioms Does RTL maintain microarchitectural orderings? Microarch. verification checks that combination of axioms satisfies MCM Microarchitectural happens-before (µhb) graphs
15 RTL Verification is Maturing but usually ignores memory consistency! Often use SystemVerilog Assertions (SVA)
16 RTL Verification is Maturing but usually ignores memory consistency! Often use SystemVerilog Assertions (SVA) ISA-Formal [Reid et al. CAV 2016] -Instr. Operational Semantics No MCM verification!
17 RTL Verification is Maturing but usually ignores memory consistency! Often use SystemVerilog Assertions (SVA) ISA-Formal [Reid et al. CAV 2016] -Instr. Operational Semantics No MCM verification! DOGReL [Stewart et al. DIFTS 2014] -Memory subsystem transactions No multicore MCM verification!
18 RTL Verification is Maturing but usually ignores memory consistency! Often use SystemVerilog Assertions (SVA) ISA-Formal [Reid et al. CAV 2016] -Instr. Operational Semantics No MCM verification! DOGReL [Stewart et al. DIFTS 2014] -Memory subsystem transactions No multicore MCM verification! Kami [Vijayaraghavan et al. CAV 2015] [Choi et al. ICFP 2017] -MCM correctness for all programs, but Needs Bluespec design and manual proofs!
19 RTL Verification is Maturing but usually ignores memory consistency! Often use SystemVerilog Assertions (SVA) ISA-Formal [Reid et al. CAV 2016] -Instr. Operational Semantics No MCM verification! DOGReL [Stewart et al. DIFTS 2014] -Memory subsystem transactions Lack of automated memory No multicore MCM verification! consistency verification at RTL! Kami [Vijayaraghavan et al. CAV 2015] [Choi et al. ICFP 2017] -MCM correctness for all programs, but Needs Bluespec design and manual proofs!
20 RTLCheck: Verifying Consistency Orderings at RTL RTL Design Litmus Test µspec Microarch. Axioms Mapping Functions RTLCheck Temporal SystemVerilog Assertions (SVA) JasperGold (RTL Verifier) Proven?
21 RTLCheck: Verifying Consistency Orderings at RTL RTL Design Litmus Test µspec Microarch. Axioms RTLCheck Mapping Functions User-provided mapping functions translate microarch. primitives to RTL equivalents Temporal SystemVerilog Assertions (SVA) JasperGold (RTL Verifier) Proven?
22 RTLCheck: Verifying Consistency Orderings at RTL RTL Design Litmus Test µspec Microarch. Axioms Mapping Functions RTLCheck Temporal SystemVerilog Assertions (SVA) JasperGold (RTL Verifier) RTLCheck automatically translates µarch. ordering axioms to temporal properties Proven?
23 RTLCheck: Verifying Consistency Orderings at RTL RTL Design Litmus Test µspec Microarch. Axioms Mapping Functions RTLCheck Temporal SystemVerilog Assertions (SVA) JasperGold (RTL Verifier) Properties may be proven or counterexample found Proven?
24 Meaning can be Lost in Translation! 小心地滑
25 Meaning can be Lost in Translation! 小心地滑 (Caution: Slippery Floor)
26 Meaning can be Lost in Translation! 小心地滑 (Caution: Slippery Floor) [Image: Barbara Younger] [Inspiration: Tae Jun Ham]
27 RTLCheck: Verifying Consistency at RTL Axiomatic Microarch. Verification
28 RTLCheck: Verifying Consistency at RTL Axiomatic Microarch. Verification clk Core[0].DX St x St y Temporal RTL Verification (SVA, etc) Core[0].WB Core[0].SData St x 0x1 St y 0x1 Core[1].DX Core[1].WB Ld y Ld x Ld y Ld x Core[1].LData 0x1 0x1
29 RTLCheck: Verifying Consistency at RTL Axiomatic Microarch. Verification Abstract nodes and happensbefore edges clk Core[0].DX St x St y Temporal RTL Verification (SVA, etc) Core[0].WB Core[0].SData St x 0x1 St y 0x1 Core[1].DX Core[1].WB Ld y Ld x Ld y Ld x Core[1].LData 0x1 0x1
30 RTLCheck: Verifying Consistency at RTL Axiomatic Microarch. Verification Abstract nodes and happensbefore edges clk Core[0].DX St x St y Temporal RTL Verification (SVA, etc) Core[0].WB St x St y Core[0].SData 0x1 0x1 Core[1].DX Ld y Ld x Concrete signals and clock cycles Core[1].WB Ld y Ld x Core[1].LData 0x1 0x1
31 RTLCheck: Verifying Consistency at RTL Axiomatic Microarch. Verification Abstract nodes and happensbefore edges Axiomatic/Temporal Mismatch! clk Core[0].DX St x St y Temporal RTL Verification (SVA, etc) Core[0].WB St x St y Core[0].SData 0x1 0x1 Core[1].DX Ld y Ld x Concrete signals and clock cycles Core[1].WB Ld y Ld x Core[1].LData 0x1 0x1
32 Instances of the Axiomatic/Temporal Mismatch Outcome Filtering: enforcing particular outcome for litmus test Discussed next Mapping Individual Happens-Before Edges (detailed in paper) Filtering Match Attempts (detailed in paper)
33 Outcome Filtering in Axiomatic Verification Axiomatic models make outcome filtering easy and efficient mp (Message Passing) Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x;
34 Outcome Filtering in Axiomatic Verification Axiomatic models make outcome filtering easy and efficient mp (Message Passing) Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; Outcome: r1 = 1, r2 = 1 Execution examined as a whole, so outcome can be enforced!
35 Outcome Filtering in Axiomatic Verification Axiomatic models make outcome filtering easy and efficient mp (Message Passing) Core 0 Core 1 (i1) x = 1; (i3) r1 = y; rf (i2) y = 1; (i4) r2 = x; Outcome: r1 = 1, r2 = 1 Execution examined as a whole, so outcome can be enforced!
36 Outcome Filtering in Axiomatic Verification Axiomatic models make outcome filtering easy and efficient mp (Message Passing) Core 0 Core 1 (i1) x = 1; (i3) r1 = y; rf (i2) y = 1; (i4) r2 = x; Outcome: r1 = 1, r2 = 1 Execution examined as a whole, so outcome can be enforced!
37 Outcome Filtering in Temporal Verification Filtering executions by outcome requires expensive global analysis Not done by many SVA verifiers, including JasperGold! mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; Is r1 = 1, r2 = 0 possible?
38 Outcome Filtering in Temporal Verification Filtering executions by outcome requires expensive global analysis Not done by many SVA verifiers, including JasperGold! mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; Is r1 = 1, r2 = 0 possible? (i1) x = 1 Step 1
39 Outcome Filtering in Temporal Verification Filtering executions by outcome requires expensive global analysis Not done by many SVA verifiers, including JasperGold! mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; Is r1 = 1, r2 = 0 possible? (i1) x = 1 (i2) y = 1 (i3) r1 = y = 1 Step 1 Step 2 Step 3 (i4) r2 = x = 1 Step 4
40 Outcome Filtering in Temporal Verification Filtering executions by outcome requires expensive global analysis Not done by many SVA verifiers, including JasperGold! mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; Is r1 = 1, r2 = 0 possible? (i1) x = 1 (i2) y = 1 (i3) r1 = y = 1 Step 1 Step 2 Step 3 (i4) r2 = x = 1 Step 4 (i4) r2 = x = 0?
41 Outcome Filtering in Temporal Verification Filtering executions by outcome requires expensive global analysis Not done by many SVA verifiers, including JasperGold! (i1) x = 1 Step 1 Step 2 mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; Is r1 = 1, r2 = 0 possible? (i3) r1 = y = 0 (i2) y = 1 (i3) r1 = y = 1 Step 3 Need to examine all possible paths from current step to end of execution: too expensive! (i4) r2 = x = 1 Step 4 (i4) r2 = x = 0?
42 Outcome Filtering in Temporal Verification Filtering executions by outcome requires expensive global analysis Not done by many SVA verifiers, including JasperGold! (i1) x = 1 Step 1 Step 2 mp Core 0 Core 1 SVA Verifier Approximation: (i1) x = 1; (i3) r1 = y; possible Only paths check from if (i2) y = 1; (i4) r2 = x; current step to end of constraints hold up to current step Is r1 = 1, r2 = 0 possible? (i3) r1 = y = 0 (i2) y = 1 (i3) r1 = y = 1 Step 3 Need to examine all execution: too expensive! Makes Outcome Filtering impossible! (i4) r2 = x = 1 Step 4 (i4) r2 = x = 0?
43 Note: Axioms abstracted for brevity µspec Verification Uses Outcome Filtering mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 Axiom "Read_Values": Every load either reads BeforeAllWrites OR reads FromLatestWrite
44 Note: Axioms abstracted for brevity µspec Verification Uses Outcome Filtering mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 Axiom "Read_Values": Every load either reads BeforeAllWrites OR reads FromLatestWrite
45 Note: Axioms abstracted for brevity µspec Verification Uses Outcome Filtering mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 Axiom "Read_Values": Every load either reads BeforeAllWrites OR reads FromLatestWrite No write for load to read from!
46 Note: Axioms abstracted for brevity µspec Verification Uses Outcome Filtering mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 Axiom "Read_Values": Every load either reads BeforeAllWrites OR reads FromLatestWrite Outcome Filtering leads to simpler axioms!
47 Note: Axioms/properties abstracted for brevity Temporal Outcome Filtering Fails! BeforeAllWrites: Unless Load returns non-zero value, Load happens before all stores to its address mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0
48 Note: Axioms/properties abstracted for brevity Temporal Outcome Filtering Fails! BeforeAllWrites: Unless Load returns non-zero value, Load happens before all stores to its address mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 clk After 3 cycles: Core[0].Commit St x Core[0].SData 0x1 Core[1].Commit Core[1].LData
49 Note: Axioms/properties abstracted for brevity Temporal Outcome Filtering Fails! BeforeAllWrites: Unless Load returns non-zero value, Load happens before all stores to its address mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 clk Core[0].Commit St x After 3 cycles: Store happens before load! Property Violated? Core[0].SData 0x1 Core[1].Commit Core[1].LData
50 Note: Axioms/properties abstracted for brevity Temporal Outcome Filtering Fails! BeforeAllWrites: Unless Load returns non-zero value, Load happens before all stores to its address mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 clk Core[0].Commit St x 4 St y 5 6 After 3 cycles: Store happens before load! Property Violated? Core[0].SData Core[1].Commit 0x1 0x1 Ld y Ld x After 6 cycles: Load does not read 0 No Violation! Core[1].LData 0x1 0x1
51 Note: Axioms/properties abstracted for brevity Temporal Outcome Filtering Fails! BeforeAllWrites: Unless Load returns non-zero value, Load happens before all stores to its address mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 clk Core[0].Commit St x 4 St y 5 6 After 3 cycles: Store happens before load! Property Violated? Core[0].SData Core[1].Commit Core[1].LData 0x1 0x1 Ld y 0x1 Ld x 0x1 After 6 cycles: Load does not read 0 No Violation! But verifiers don t check future cycles!
52 Temporal Outcome Filtering Fails! BeforeAllWrites: Unless Load returns non-zero value, Load happens before all stores to its address mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 clk Core[0].Commit Core[0].SData Core[1].Commit Core[1].LData St x 0x1 Counterexample flagged despite hardware doing nothing wrong! After 3 cycles: Store happens before load! Property Violated? After 6 cycles: Load does not read 0 No Violation! But verifiers don t check future cycles! Note: Axioms/properties abstracted for brevity
53 Note: Axioms and properties abstracted for brevity Solution: Load Value Constraints Don t simplify axioms; translate all cases Tag each case with appropriate load value constraints reflect the data constraints required for edge(s) mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 Axiom "Read_Values": Every load either reads BeforeAllWrites OR reads FromLatestWrite Property to check: mapnode(ld x St x, Ld x == 0) or mapnode(st x Ld x, Ld x == 1);
54 Note: Axioms and properties abstracted for brevity Solution: Load Value Constraints Don t simplify axioms; translate all cases Tag each case with appropriate load value constraints reflect the data constraints required for edge(s) mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 Axiom "Read_Values": Every load either reads BeforeAllWrites OR reads FromLatestWrite Property to check: mapnode(ld x St x, Ld x == 0) or mapnode(st x Ld x, Ld x == 1);
55 Note: Axioms and properties abstracted for brevity Solution: Load Value Constraints Don t simplify axioms; translate all cases Tag each case with appropriate load value constraints reflect the data constraints required for edge(s) mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 Axiom "Read_Values": Every load either reads BeforeAllWrites OR reads FromLatestWrite Property to check: mapnode(ld x St x, Ld x == 0) or mapnode(st x Ld x, Ld x == 1);
56 Note: Axioms and properties abstracted for brevity Solution: Load Value Constraints Don t simplify axioms; translate all cases Tag each case with appropriate load value constraints reflect the data constraints required for edge(s) mp Core 0 Core 1 (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; SC Forbids: r1 = 1, r2 = 0 Axiom "Read_Values": Every load either reads BeforeAllWrites OR reads FromLatestWrite Property to check: mapnode(ld x St x, Ld x == 0) or mapnode(st x Ld x, Ld x == 1);
57 Multi-V-scale: a Multicore Case Study Core 0 Core 1 Core 2 Core 3 IF IF IF IF DX DX DX DX WB WB WB WB Arbiter Memory
58 Multi-V-scale: a Multicore Case Study Core 0 Core 1 Core 2 Core 3 IF IF IF IF 3-stage in-order pipelines DX WB DX WB DX WB DX WB Arbiter Memory
59 Multi-V-scale: a Multicore Case Study Core 0 Core 1 Core 2 Core 3 IF IF IF IF DX DX DX DX WB WB WB Arbiter Memory WB Arbiter enforces that only one core can access memory at any time
60 Bug Discovered in V-scale V-scale memory internally writes stores to wdata register wdata pushed to memory when subsequent store occurs Akin to single-entry store buffer When two stores are sent to memory in successive cycles, first of two stores is dropped by memory! Fixed bug by eliminating wdata V-scale has since been deprecated by RISC-V Foundation Core 0 Core 1 Core 2 Core 3 IF y DX = 1 WB x = 1 Stores IF DX WB wdata Arbiter IF DX WB IF DX WB Memory Mem array
61 Bug Discovered in V-scale V-scale memory internally writes stores to wdata register wdata pushed to memory when subsequent store occurs Akin to single-entry store buffer When two stores are sent to memory in successive cycles, first of two stores is dropped by memory! Fixed bug by eliminating wdata V-scale has since been deprecated by RISC-V Foundation Core 0 Core 1 Core 2 Core 3 IF y DX = 1 WB x = 1 Stores IF DX WB wdata Arbiter IF DX WB IF DX WB Memory Mem array
62 Bug Discovered in V-scale V-scale memory internally writes stores to wdata register wdata pushed to memory when subsequent store occurs Akin to single-entry store buffer When two stores are sent to memory in successive cycles, first of two stores is dropped by memory! Fixed bug by eliminating wdata V-scale has since been deprecated by RISC-V Foundation Core 0 Core 1 Core 2 Core 3 IF DX WB Stores IF DX WB wdata y x = 1 Arbiter IF DX WB IF DX WB Memory Mem array
63 safe006 lb safe007 mp safe022 safe010 ssl safe000 safe008 n4 n5 co-mp safe001 wrc sb safe018 podwr000 safe003 mp+staleld safe012 safe002 safe014 iwp23b safe009 safe029 safe027 rwc n2 rfi013 safe030 safe011 rfi015 rfi003 safe021 iriw n7 iwp24 podwr001 safe017 rfi012 n6 safe019 rfi001 rfi000 rfi011 safe026 safe004 safe016 rfi002 rfi005 rfi014 rfi004 rfi006 n1 amd3 co-iriw Mean Time (hours) Results: Time to Verification Two configurations (Hybrid and Full_Proof), avg. runtime 6.2 hrs See paper for configuration details Hybrid Full_Proof
64 safe006 lb safe007 mp safe022 safe010 ssl safe000 safe008 n4 n5 co-mp safe001 wrc sb safe018 podwr000 safe003 mp+staleld safe012 safe002 safe014 iwp23b safe009 safe029 safe027 rwc n2 rfi013 safe030 safe011 rfi015 rfi003 safe021 iriw n7 iwp24 podwr001 safe017 rfi012 n6 safe019 rfi001 rfi000 rfi011 safe026 safe004 safe016 rfi002 rfi005 rfi014 rfi004 rfi006 n1 amd3 co-iriw Mean Time (hours) Results: Time to Verification Two configurations (Hybrid and Full_Proof), avg. runtime 6.2 hrs See paper for configuration details Hybrid Verified very quickly through covering traces (details in paper) Full_Proof
65 safe006 lb safe007 mp safe022 safe010 ssl safe000 safe008 n4 n5 co-mp safe001 wrc sb safe018 podwr000 safe003 mp+staleld safe012 safe002 safe014 iwp23b safe009 safe029 safe027 rwc n2 rfi013 safe030 safe011 rfi015 rfi003 safe021 iriw n7 iwp24 podwr001 safe017 rfi012 n6 safe019 rfi001 rfi000 rfi011 safe026 safe004 safe016 rfi002 rfi005 rfi014 rfi004 rfi006 n1 amd3 co-iriw Mean Time (hours) Results: Time to Verification Two configurations (Hybrid and Full_Proof), avg. runtime 6.2 hrs See paper for configuration details Hybrid Full_Proof Max runtime 11 hours (if some properties unproven)
66 safe006 lb safe007 safe000 n4 safe011 safe016 safe030 rfi000 safe017 safe019 safe004 safe021 rfi011 rfi006 n1 rfi012 n7 co-iriw rfi005 safe002 n2 iriw rfi002 safe012 rfi003 safe003 safe014 safe001 iwp24 rfi015 rfi001 safe026 safe027 podwr001 safe008 rfi014 n6 n5 wrc safe018 rwc safe009 rfi004 amd3 mp+staleld rfi013 mp safe022 safe010 ssl co-mp sb podwr000 iwp23b safe029 Mean % Proven Properties Results: Proven Properties Full_Proof generally better (90%/test) than Hybrid (81%/test) On average, Full_Proof can prove more properties in same time Hybrid Full_Proof
67 safe006 lb safe007 safe000 n4 safe011 safe016 safe030 rfi000 safe017 safe019 safe004 safe021 rfi011 rfi006 n1 rfi012 n7 co-iriw rfi005 safe002 n2 iriw rfi002 safe012 rfi003 safe003 safe014 safe001 iwp24 rfi015 rfi001 safe026 safe027 podwr001 safe008 rfi014 n6 n5 wrc safe018 rwc safe009 rfi004 amd3 mp+staleld rfi013 mp safe022 safe010 ssl co-mp sb podwr000 iwp23b safe029 Mean % Proven Properties Results: Proven Properties Full_Proof generally better (90%/test) than Hybrid (81%/test) On average, Full_Proof can prove more properties in same time Hybrid better for only a few tests Hybrid Full_Proof
68 MCM Verification: The Big Picture High-Level Languages (HLL) [Batty et al. POPL 2012] [TriCheck, ASPLOS 2017] Compiler OS [COATCheck, ASPLOS 2016] [Vafeiadis et al. PLDI 2017] Architecture [Sarkar et al. PLDI 2011] [Alglave et al. TOPLAS 2014] Microarchitecture Processor RTL [PipeCheck, MICRO-47] [CCICheck, MICRO-48] [Vijayaraghavan et al. CAV 2015] [Choi et al. ICFP 2017]
69 MCM Verification: The Big Picture High-Level Languages (HLL) Compiler OS Architecture [Batty et al. POPL 2012] [TriCheck, ASPLOS 2017] [COATCheck, ASPLOS 2016] [Vafeiadis et al. PLDI 2017] [Sarkar et al. PLDI 2011] [Alglave et al. TOPLAS 2014] Higher-level tools directly or indirectly assume correctness of underlying RTL! Microarchitecture Processor RTL [PipeCheck, MICRO-47] [CCICheck, MICRO-48] [Vijayaraghavan et al. CAV 2015] [Choi et al. ICFP 2017]
70 MCM Verification: The Big Picture High-Level Languages (HLL) Compiler OS Architecture [Batty et al. POPL 2012] [TriCheck, ASPLOS 2017] [COATCheck, ASPLOS 2016] [Vafeiadis et al. PLDI 2017] [Sarkar et al. PLDI 2011] [Alglave et al. TOPLAS 2014] Higher-level tools directly or indirectly assume correctness of underlying RTL! Microarchitecture Processor RTL [PipeCheck, MICRO-47] [CCICheck, MICRO-48] [Vijayaraghavan et al. CAV 2015] [Choi et al. ICFP 2017] Requires Bluespec design and manual proof
71 MCM Verification: The Big Picture High-Level Languages (HLL) Compiler OS Architecture [Batty et al. POPL 2012] [TriCheck, ASPLOS 2017] [COATCheck, ASPLOS 2016] [Vafeiadis et al. PLDI 2017] [Sarkar et al. PLDI 2011] [Alglave et al. TOPLAS 2014] Higher-level tools directly or indirectly assume correctness of underlying RTL! Microarchitecture [PipeCheck, MICRO-47] [CCICheck, MICRO-48] Processor RTL [RTLCheck, MICRO-50] [Vijayaraghavan et al. CAV 2015] [Choi et al. ICFP 2017] RTLCheck validates RTL against µarch, filling µarch-rtl verification gap! Automated MCM verification of arbitrary RTL for suite of litmus tests
72 Conclusions RTLCheck: Automated MCM Verification of arbitrary RTL against arbitrary microarchitectural orderings Translates microarch. axioms into equivalent temporal SVA properties Allows RTL to be validated against µarch ordering specification Capable of handling arbitrary ISA-level MCMs (SC, TSO, ARM, Power, ) Most of generated properties proven by JasperGold in minutes or hours RTLCheck enables full-stack HLL-to-RTL MCM verification (with rest of Check suite) across a collection of litmus tests Code available at
73 RTLCheck: Verifying the Memory Consistency of RTL Designs Yatin A. Manerkar, Daniel Lustig*, Margaret Martonosi, and Michael Pellauer* Code available at
RTLCheck: Verifying the Memory Consistency of RTL Designs
RTLCheck: Verifying the Memory Consistency of RTL Designs ABSTRACT Yatin A. Manerkar Daniel Lustig Margaret Martonosi Michael Pellauer Princeton University NVIDIA {manerkar,mrm}@princeton.edu {dlustig,mpellauer}@nvidia.com
CCICheck: Using µhb Graphs to Verify the Coherence-Consistency Interface
CCICheck: Using µhb Graphs to Verify the Coherence-Consistency Interface Yatin A. Manerkar, Daniel Lustig, Michael Pellauer*, and Margaret Martonosi Princeton University *NVIDIA MICRO-48 1 Coherence and
Research Faculty Summit Systems Fueling future disruptions
Research Faculty Summit 2018 Systems Fueling future disruptions Hardware-Aware Security Verification and Synthesis Margaret Martonosi H. T. Adams 35 Professor Dept. of Computer Science Princeton University
TriCheck: Memory Model Verification at the Trisection of Software, Hardware, and ISA
TriCheck: Verification at the Trisection of Software, Hardware, and ISA Caroline Trippel, Yatin A. Manerkar, Daniel Lustig*, Michael Pellauer*, Margaret Martonosi Princeton University *NVIDIA ASPLOS 2017
PipeProof: Automated Memory Consistency Proofs for Microarchitectural Specifications
PipeProof: Automated Memory Consistency Proofs for Microarchitectural Specifications Yatin A. Manerkar Daniel Lustig Margaret Martonosi Aarti Gupta Princeton University NVIDIA {manerkar,mrm,aartig}@princeton.edu
C11 Compiler Mappings: Exploration, Verification, and Counterexamples
C11 Compiler Mappings: Exploration, Verification, and Counterexamples Yatin Manerkar Princeton University manerkar@princeton.edu http://check.cs.princeton.edu November 22 nd, 2016 1 Compilers Must Uphold
Check Quick Start. Figure 1: Closeup of icon for starting a terminal window.
Check Quick Start 1 Getting Started 1.1 Downloads The tools in the tutorial are distributed to work within VirtualBox. If you don t already have Virtual Box installed, please download VirtualBox from this
Full-Stack Memory Model Verification with TriCheck
THEME ARTICLE: Top Picks Full-Stack Memory Model Verification with TriCheck Caroline Trippel and Yatin A. Manerkar Princeton University Daniel Lustig and Michael Pellauer Nvidia Margaret Martonosi Princeton
TriCheck: Memory Model Verification at the Trisection of Software, Hardware, and ISA
TriCheck: Memory Model Verification at the Trisection of Software, Hardware, and ISA Caroline Trippel Yatin A. Manerkar Daniel Lustig* Michael Pellauer* Margaret Martonosi Princeton University *NVIDIA
TRANSISTENCY MODELS:MEMORY ORDERING AT THE HARDWARE OS INTERFACE
... TRANSISTENCY MODELS:MEMORY ORDERING AT THE HARDWARE OS INTERFACE... Daniel Lustig Princeton University Geet Sethi Abhishek Bhattacharjee Rutgers University Margaret Martonosi Princeton University THIS
TriCheck: Memory Model Verification at the Trisection of Software, Hardware, and ISA
TriCheck: Memory Model Verification at the Trisection of Software, Hardware, and ISA Caroline Trippel Yatin A. Manerkar Daniel Lustig* Michael Pellauer* Margaret Martonosi Princeton University {ctrippel,manerkar,mrm}@princeton.edu
Formal for Everyone Challenges in Achievable Multicore Design and Verification. FMCAD 25 Oct 2012 Daryl Stewart
Formal for Everyone Challenges in Achievable Multicore Design and Verification FMCAD 25 Oct 2012 Daryl Stewart 1 ARM is an IP company ARM licenses technology to a network of more than 1000 partner companies
Kami: A Framework for (RISC-V) HW Verification
Kami: A Framework for (RISC-V) HW Verification Murali Vijayaraghavan Joonwon Choi, Adam Chlipala, (Ben Sherman), Andy Wright, Sizhuo Zhang, Thomas Bourgeat, Arvind 1 The Riscy Expedition by MIT Riscy Library
Constructing a Weak Memory Model
Constructing a Weak Memory Model Sizhuo Zhang 1, Muralidaran Vijayaraghavan 1, Andrew Wright 1, Mehdi Alipour 2, Arvind 1 1 MIT CSAIL 2 Uppsala University ISCA 2018, Los Angeles, CA 06/04/2018 1 The Specter
Relaxed Memory: The Specification Design Space
Relaxed Memory: The Specification Design Space Mark Batty University of Cambridge Fortran meeting, Delft, 25 June 2013 1 An ideal specification Unambiguous Easy to understand Sound w.r.t. experimentally
TSO-CC: Consistency-directed Coherence for TSO. Vijay Nagarajan
TSO-CC: Consistency-directed Coherence for TSO Vijay Nagarajan 1 People Marco Elver (Edinburgh) Bharghava Rajaram (Edinburgh) Changhui Lin (Samsung) Rajiv Gupta (UCR) Susmit Sarkar (St Andrews) 2 Multicores
CCICheck: Using µhb Graphs to Verify the Coherence-Consistency Interface
Iheck: Using µhb Graphs to Verify the oherence-onsistency Interface Yatin A. Manerkar Daniel Lustig Michael Pellauer Margaret Martonosi Princeton University NVIDIA {manerkar,dlustig,mrm}@princeton.edu
Formal Specification of RISC-V Systems Instructions
Formal Specification of RISC-V Systems Instructions Arvind Andy Wright, Sizhuo Zhang, Thomas Bourgeat, Murali Vijayaraghavan Computer Science and Artificial Intelligence Lab. MIT RISC-V Workshop, MIT,
A Memory Model for RISC-V
A Memory Model for RISC-V Arvind (joint work with Sizhuo Zhang and Muralidaran Vijayaraghavan) Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology Barcelona Supercomputer
Understanding POWER multiprocessors
Understanding POWER multiprocessors Susmit Sarkar 1 Peter Sewell 1 Jade Alglave 2,3 Luc Maranget 3 Derek Williams 4 1 University of Cambridge 2 Oxford University 3 INRIA 4 IBM June 2011 Programming shared-memory
GPU Concurrency: Weak Behaviours and Programming Assumptions
GPU Concurrency: Weak Behaviours and Programming Assumptions Jyh-Jing Hwang, Yiren(Max) Lu 03/02/2017 Outline 1. Introduction 2. Weak behaviors examples 3. Test methodology 4. Proposed memory model 5.
Program logics for relaxed consistency
Program logics for relaxed consistency UPMARC Summer School 2014 Viktor Vafeiadis Max Planck Institute for Software Systems (MPI-SWS) 1st Lecture, 28 July 2014 Outline Part I. Weak memory models 1. Intro
arxiv: v1 [cs.pl] 29 Aug 2018
![arxiv: v1 [cs.pl] 29 Aug 2018](/thumbs/89/100118233.jpg "arxiv: v1 [cs.pl] 29 Aug 2018")
Memory Consistency Models using Constraints Özgür Akgün, Ruth Hoffmann, and Susmit Sarkar arxiv:1808.09870v1 [cs.pl] 29 Aug 2018 School of Computer Science, University of St Andrews, UK {ozgur.akgun, rh347,
An introduction to weak memory consistency and the out-of-thin-air problem
An introduction to weak memory consistency and the out-of-thin-air problem Viktor Vafeiadis Max Planck Institute for Software Systems (MPI-SWS) CONCUR, 7 September 2017 Sequential consistency 2 Sequential
The Bulk Multicore Architecture for Programmability
The Bulk Multicore Architecture for Programmability Department of Computer Science University of Illinois at Urbana-Champaign http://iacoma.cs.uiuc.edu Acknowledgments Key contributors: Luis Ceze Calin
Strong Formal Verification for RISC-V From Instruction-Set Manual to RTL
Strong Formal Verification for RISC-V From Instruction-Set Manual to RTL Adam Chlipala MIT CSAIL RISC-V Workshop November 2017 Joint work with: Arvind, Thomas Bourgeat, Joonwon Choi, Ian Clester, Samuel
Taming release-acquire consistency
Taming release-acquire consistency Ori Lahav Nick Giannarakis Viktor Vafeiadis Max Planck Institute for Software Systems (MPI-SWS) POPL 2016 Weak memory models Weak memory models provide formal sound semantics
Moscova. Jean-Jacques Lévy. March 23, INRIA Paris Rocquencourt
Moscova Jean-Jacques Lévy INRIA Paris Rocquencourt March 23, 2011 Research team Stats Staff 2008-2011 Jean-Jacques Lévy, INRIA Karthikeyan Bhargavan, INRIA James Leifer, INRIA Luc Maranget, INRIA Francesco
HAsim: FPGA-Based Micro-Architecture Simulator
HAsim: FPGA-Based Micro-Architecture Simulator Michael Adler Michael Pellauer Kermin E. Fleming* Angshuman Parashar Joel Emer *MIT HAsim Is a Timing Model Not RTL! Performance models are: Highly parallel,
A Trustworthy Monadic Formalization of the ARMv7 Instruction Set Architecture. Anthony Fox and Magnus O. Myreen University of Cambridge
A Trustworthy Monadic Formalization of the ARMv7 Instruction Set Architecture Anthony Fox and Magnus O. Myreen University of Cambridge Background Instruction set architectures play an important role in
Weak Memory Models with Matching Axiomatic and Operational Definitions
Weak Memory Models with Matching Axiomatic and Operational Definitions Sizhuo Zhang 1 Muralidaran Vijayaraghavan 1 Dan Lustig 2 Arvind 1 1 {szzhang, vmurali, arvind}@csail.mit.edu 2 dlustig@nvidia.com
High-Level Information Interface
High-Level Information Interface Deliverable Report: SRC task 1875.001 - Jan 31, 2011 Task Title: Exploiting Synergy of Synthesis and Verification Task Leaders: Robert K. Brayton and Alan Mishchenko Univ.
From POPL to the Jungle and back
From POPL to the Jungle and back Peter Sewell University of Cambridge PLMW: the SIGPLAN Programming Languages Mentoring Workshop San Diego, January 2014 p.1 POPL 2014 41th ACM SIGPLAN-SIGACT Symposium
Bluespec SystemVerilog TM Training. Lecture 05: Rules. Copyright Bluespec, Inc., Lecture 05: Rules
Bluespec SystemVerilog Training Copyright Bluespec, Inc., 2005-2008 Rules: conditions, actions Rule Untimed Semantics Non-determinism Functional correctness: atomicity, invariants Examples Performance
Pipelining. CSC Friday, November 6, 2015
Pipelining CSC 211.01 Friday, November 6, 2015 Performance Issues Longest delay determines clock period Critical path: load instruction Instruction memory register file ALU data memory register file Not
Memory Access Scheduler
Memory Access Scheduler Matt Cohen and Alvin Lin 6.884 Final Project Report May 10, 2005 1 Introduction We propose to implement a non-blocking memory system based on the memory access scheduler described
Formal Technology in the Post Silicon lab
Formal Technology in the Post Silicon lab Real-Life Application Examples Haifa Verification Conference Jamil R. Mazzawi Lawrence Loh Jasper Design Automation Focus of This Presentation Finding bugs in
Hardware models: inventing a usable abstraction for Power/ARM. Friday, 11 January 13
Hardware models: inventing a usable abstraction for Power/ARM 1 Hardware models: inventing a usable abstraction for Power/ARM Disclaimer: 1. ARM MM is analogous to Power MM all this is your next phone!
Mechanised industrial concurrency specification: C/C++ and GPUs. Mark Batty University of Kent
Mechanised industrial concurrency specification: C/C++ and GPUs Mark Batty University of Kent It is time for mechanised industrial standards Specifications are written in English prose: this is insufficient
ISCA Tutorial Reading List
ISCA Tutorial Reading List Caroline Trippel Yatin A. Manerkar Margaret Martonosi Princeton University {ctrippel,manerkar,mrm}@princeton.edu June, 2017 References [1] Sarita Adve and Kourosh Gharachorloo.
ON THE EFFECTIVENESS OF ASSERTION-BASED VERIFICATION
ON THE EFFECTIVENESS OF ASSERTION-BASED VERIFICATION IN AN INDUSTRIAL CONTEXT L.Pierre, F.Pancher, R.Suescun, J.Quévremont TIMA Laboratory, Grenoble, France Dolphin Integration, Meylan, France Thales Communications
Muralidaran Vijayaraghavan
Muralidaran Vijayaraghavan Contact Information 32 Vassar Street 32-G822, Cambridge MA 02139 Mobile: +1 408 839 3356 Homepage: http://people.csail.mit.edu/vmurali Email: vmurali@csail.mit.edu Education
Designing Memory Consistency Models for. Shared-Memory Multiprocessors. Sarita V. Adve
Designing Memory Consistency Models for Shared-Memory Multiprocessors Sarita V. Adve Computer Sciences Department University of Wisconsin-Madison The Big Picture Assumptions Parallel processing important
Hybrid Verification in SPARK 2014: Combining Formal Methods with Testing
IEEE Software Technology Conference 2015 Hybrid Verification in SPARK 2014: Combining Formal Methods with Testing Steve Baird Senior Software Engineer Copyright 2014 AdaCore Slide: 1 procedure Array_Indexing_Bug
arxiv: v1 [cs.cr] 11 Feb 2018
![arxiv: v1 [cs.cr] 11 Feb 2018](/thumbs/75/72154667.jpg "arxiv: v1 [cs.cr] 11 Feb 2018")
MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols Caroline Trippel Daniel Lustig* Margaret Martonosi Princeton University *NVIDIA {ctrippel,mrm@princetonedu
Declarative semantics for concurrency. 28 August 2017
Declarative semantics for concurrency Ori Lahav Viktor Vafeiadis 28 August 2017 An alternative way of defining the semantics 2 Declarative/axiomatic concurrency semantics Define the notion of a program
Sequential Consistency & TSO. Subtitle
Sequential Consistency & TSO Subtitle Core C1 Core C2 data = 0, 1lag SET S1: store data = NEW S2: store 1lag = SET L1: load r1 = 1lag B1: if (r1 SET) goto L1 L2: load r2 = data; Will r2 always be set to
Unit 12: Memory Consistency Models. Includes slides originally developed by Prof. Amir Roth
Unit 12: Memory Consistency Models Includes slides originally developed by Prof. Amir Roth 1 Example #1 int x = 0;! int y = 0;! thread 1 y = 1;! thread 2 int t1 = x;! x = 1;! int t2 = y;! print(t1,t2)!
A concrete memory model for CompCert
A concrete memory model for CompCert Frédéric Besson Sandrine Blazy Pierre Wilke Rennes, France P. Wilke A concrete memory model for CompCert 1 / 28 CompCert real-world C to ASM compiler used in industry
Hardware-Software Codesign. 9. Worst Case Execution Time Analysis
Hardware-Software Codesign 9. Worst Case Execution Time Analysis Lothar Thiele 9-1 System Design Specification System Synthesis Estimation SW-Compilation Intellectual Prop. Code Instruction Set HW-Synthesis
Complex Pipelines and Branch Prediction
Complex Pipelines and Branch Prediction Daniel Sanchez Computer Science & Artificial Intelligence Lab M.I.T. L22-1 Processor Performance Time Program Instructions Program Cycles Instruction CPI Time Cycle
TSOtool: A Program for Verifying Memory Systems Using the Memory Consistency Model
TSOtool: A Program for Verifying Memory Systems Using the Memory Consistency Model Sudheendra Hangal, Durgam Vahia, Chaiyasit Manovit, Joseph Lu and Sridhar Narayanan tsotool@sun.com ISCA-2004 Sun Microsystems
Pattern-based Synthesis of Synchronization for the C++ Memory Model
Pattern-based Synthesis of Synchronization for the C++ Memory Model Yuri Meshman Technion Noam Rinetzky Tel Aviv University Eran Yahav Technion Abstract We address the problem of synthesizing efficient
The Processor: Instruction-Level Parallelism
The Processor: Instruction-Level Parallelism Computer Organization Architectures for Embedded Computing Tuesday 21 October 14 Many slides adapted from: Computer Organization and Design, Patterson & Hennessy
SECOMP Efficient Formally Secure Compilers to a Tagged Architecture. Cătălin Hrițcu INRIA Paris
SECOMP Efficient Formally Secure Compilers to a Tagged Architecture Cătălin Hrițcu INRIA Paris 1 SECOMP Efficient Formally Secure Compilers to a Tagged Architecture Cătălin Hrițcu INRIA Paris 5 year vision
High Performance SMIPS Processor
High Performance SMIPS Processor Jonathan Eastep 6.884 Final Project Report May 11, 2005 1 Introduction 1.1 Description This project will focus on producing a high-performance, single-issue, in-order,
Don t sit on the fence: A static analysis approach to automatic fence insertion
Don t sit on the fence: A static analysis approach to automatic fence insertion Power, ARM! SC! \ / ~. ~ ) / ( / / \_/ \ / /\ / \ Jade Alglave, Daniel Kroening, Vincent Nimal, Daniel Poetzl University
The University of Michigan - Department of EECS EECS578 Correct Operation for Processor and Embedded Systems Midterm exam December 3, 2015
The University of Michigan - Department of EECS EECS578 Correct Operation for Processor and Embedded Systems Midterm exam December 3, 2015 Name: This exam is CLOSED BOOKS, CLOSED NOTES. You can only have
Formal Verification Adoption. Mike Bartley TVS, Founder and CEO
Formal Verification Adoption Mike Bartley TVS, Founder and CEO Agenda Some background on your speaker Formal Verification An introduction Basic examples A FIFO example Adoption Copyright TVS Limited Private
Verification by the book: ISA Formal at ARM
Verification by the book: ISA Formal at ARM Will Keen Senior Engineer, CPU Group ARM Ltd TVS Formal Verification Conference 27/06/2017 Roadmap Problem: CPU verification is really hard! Verification by
RELAXED CONSISTENCY 1
RELAXED CONSISTENCY 1 RELAXED CONSISTENCY Relaxed Consistency is a catch-all term for any MCM weaker than TSO GPUs have relaxed consistency (probably) 2 XC AXIOMS TABLE 5.5: XC Ordering Rules. An X Denotes
Chapter 4 The Processor 1. Chapter 4B. The Processor
Chapter 4 The Processor 1 Chapter 4B The Processor Chapter 4 The Processor 2 Control Hazards Branch determines flow of control Fetching next instruction depends on branch outcome Pipeline can t always
Materials: 1. Projectable Version of Diagrams 2. MIPS Simulation 3. Code for Lab 5 - part 1 to demonstrate using microprogramming
CS311 Lecture: CPU Control: Hardwired control and Microprogrammed Control Last revised October 18, 2007 Objectives: 1. To explain the concept of a control word 2. To show how control words can be generated
administrivia final hour exam next Wednesday covers assembly language like hw and worksheets
administrivia final hour exam next Wednesday covers assembly language like hw and worksheets today last worksheet start looking at more details on hardware not covered on ANY exam probably won t finish
Memory Consistency Models. CSE 451 James Bornholt
Memory Consistency Models CSE 451 James Bornholt Memory consistency models The short version: Multiprocessors reorder memory operations in unintuitive, scary ways This behavior is necessary for performance
Control Hazards - branching causes problems since the pipeline can be filled with the wrong instructions.
Control Hazards - branching causes problems since the pipeline can be filled with the wrong instructions Stage Instruction Fetch Instruction Decode Execution / Effective addr Memory access Write-back Abbreviation
An Operational and Axiomatic Semantics for Non-determinism and Sequence Points in C
An Operational and Axiomatic Semantics for Non-determinism and Sequence Points in C Robbert Krebbers Radboud University Nijmegen January 22, 2014 @ POPL, San Diego, USA 1 / 16 What is this program supposed
Chapter 4. The Processor
Chapter 4 The Processor Introduction CPU performance factors Instruction count Determined by ISA and compiler CPI and Cycle time Determined by CPU hardware We will examine two MIPS implementations A simplified
Computer Performance Evaluation and Benchmarking. EE 382M Dr. Lizy Kurian John
Computer Performance Evaluation and Benchmarking EE 382M Dr. Lizy Kurian John Evolution of Single-Chip Transistor Count 10K- 100K Clock Frequency 0.2-2MHz Microprocessors 1970 s 1980 s 1990 s 2010s 100K-1M
Industrial concurrency specification for C/C++ Mark Batty University of Kent
Industrial concurrency specification for C/C++ Mark Batty University of Kent It is time for mechanised industrial standards Specifications are written in English prose: this is insufficient Write mechanised
Lecture 8: Instruction Fetch, ILP Limits. Today: advanced branch prediction, limits of ILP (Sections , )
Lecture 8: Instruction Fetch, ILP Limits Today: advanced branch prediction, limits of ILP (Sections 3.4-3.5, 3.8-3.14) 1 1-Bit Prediction For each branch, keep track of what happened last time and use
Improvement: Correlating Predictors
Improvement: Correlating Predictors different branches may be correlated outcome of branch depends on outcome of other branches makes intuitive sense (programs are written this way) e.g., if the first
Secure Virtual Architecture. John Criswell University of Illinois at Urbana- Champaign
Secure Virtual Architecture John Criswell University of Illinois at Urbana- Champaign Secure Virtual Machine Software LLVA VM Hardware Virtual ISA Native ISA What is it? A compiler-based virtual machine
Relaxed Memory Consistency
Relaxed Memory Consistency Jinkyu Jeong (jinkyu@skku.edu) Computer Systems Laboratory Sungkyunkwan University http://csl.skku.edu SSE3054: Multicore Systems, Spring 2017, Jinkyu Jeong (jinkyu@skku.edu)
Assertion-Based Verification
Assertion-Based Verification ABV and Formal Property Checking Harry Foster Chief Scientist Verification info@verificationacademy.com www.verificationacademy.com Session Overview After completing this session
Specifying, Verifying, and Translating. Between Memory Consistency Models
Specifying, Verifying, and Translating Between Memory Consistency Models Daniel Joseph Lustig A Dissertation Presented to the Faculty of Princeton University in Candidacy for the Degree of Doctor of Philosophy
Instruction Level Parallelism. Appendix C and Chapter 3, HP5e
Instruction Level Parallelism Appendix C and Chapter 3, HP5e Outline Pipelining, Hazards Branch prediction Static and Dynamic Scheduling Speculation Compiler techniques, VLIW Limits of ILP. Implementation
Real Processors. Lecture for CPSC 5155 Edward Bosworth, Ph.D. Computer Science Department Columbus State University
Real Processors Lecture for CPSC 5155 Edward Bosworth, Ph.D. Computer Science Department Columbus State University Instruction-Level Parallelism (ILP) Pipelining: executing multiple instructions in parallel
Automated Synthesis of Comprehensive Memory Model Litmus Test Suites
Automated Synthesis of Comprehensive Memory Model Litmus Test Suites Daniel Lustig Andrew Wright Alexandros Papakonstantinou Olivier Giroux NVIDIA dlustig@nvidia.com MIT acwright@mit.edu NVIDIA alexandrosp@nvidia.com
What is a compiler? Xiaokang Qiu Purdue University. August 21, 2017 ECE 573
What is a compiler? Xiaokang Qiu Purdue University ECE 573 August 21, 2017 What is a compiler? What is a compiler? Traditionally: Program that analyzes and translates from a high level language (e.g.,
CPU Pipelining Issues
CPU Pipelining Issues What have you been beating your head against? This pipe stuff makes my head hurt! L17 Pipeline Issues & Memory 1 Pipelining Improve performance by increasing instruction throughput
ECE 587 Hardware/Software Co-Design Lecture 11 Verification I
ECE 587 Hardware/Software Co-Design Spring 2018 1/23 ECE 587 Hardware/Software Co-Design Lecture 11 Verification I Professor Jia Wang Department of Electrical and Computer Engineering Illinois Institute
CS 252 Graduate Computer Architecture. Lecture 4: Instruction-Level Parallelism
CS 252 Graduate Computer Architecture Lecture 4: Instruction-Level Parallelism Krste Asanovic Electrical Engineering and Computer Sciences University of California, Berkeley http://wwweecsberkeleyedu/~krste
An Abstract Stack Based Approach to Verified Compositional Compilation to Machine Code
An Abstract Stack Based Approach to Verified Compositional Compilation to Machine Code Yuting Wang 1, Pierre Wilke 1,2, Zhong Shao 1 Yale University 1, CentraleSupélec 2 POPL 19 January 18 th, 2019 Yuting
Formal Verification of Stack Manipulation in the SCIP Processor. J. Aaron Pendergrass
Formal Verification of Stack Manipulation in the SCIP Processor J. Aaron Pendergrass High Level Challenges to developing capability in formal methods: Perceived high barrier to entry, Specialized tools
Instr. execution impl. view
Pipelining Sangyeun Cho Computer Science Department Instr. execution impl. view Single (long) cycle implementation Multi-cycle implementation Pipelined implementation Processing an instruction Fetch instruction
Practical Approaches to Formal Verification. Mike Bartley, TVS
Practical Approaches to Formal Verification Mike Bartley, TVS 1 Acknowledgements This paper is based on work performed by TVS with ARM Specific thanks should go to Laurent Arditi Bryan Dickman Daryl Stuart
MIPS Pipelining. Computer Organization Architectures for Embedded Computing. Wednesday 8 October 14
MIPS Pipelining Computer Organization Architectures for Embedded Computing Wednesday 8 October 14 Many slides adapted from: Computer Organization and Design, Patterson & Hennessy 4th Edition, 2011, MK
Memory Consistency Models
Memory Consistency Models Contents of Lecture 3 The need for memory consistency models The uniprocessor model Sequential consistency Relaxed memory models Weak ordering Release consistency Jonas Skeppstedt
COMPUTER ORGANIZATION AND DESI
COMPUTER ORGANIZATION AND DESIGN 5 Edition th The Hardware/Software Interface Chapter 4 The Processor 4.1 Introduction Introduction CPU performance factors Instruction count Determined by ISA and compiler
System Correctness. EEC 421/521: Software Engineering. System Correctness. The Problem at Hand. A system is correct when it meets its requirements
System Correctness EEC 421/521: Software Engineering A Whirlwind Intro to Software Model Checking A system is correct when it meets its requirements a design without requirements cannot be right or wrong,
Simulink Verification and Validation
Simulink Verification and Validation Mark Walker MathWorks 7 th October 2014 2014 The MathWorks, Inc. 1 V Diagrams 3 When to Stop? A perfectly tested design would never be released Time spent on V&V is
3/12/2014. Single Cycle (Review) CSE 2021: Computer Organization. Single Cycle with Jump. Multi-Cycle Implementation. Why Multi-Cycle?
CSE 2021: Computer Organization Single Cycle (Review) Lecture-10b CPU Design : Pipelining-1 Overview, Datapath and control Shakil M. Khan 2 Single Cycle with Jump Multi-Cycle Implementation Instruction:
DOVER A Metadata- Extended RISC- V
DOVER A Metadata- Extended RISC- V André DeHon andre@acm.org Eli Boling, Rishiyur Nikhil, Darius Rad, Julie Schwarz Niraj Sharma, Joseph Stoy, Greg Sullivan, Andrew Sutherland Draper 1/6/2016 1 Story Non-
Leveraging Formal Verification Throughout the Entire Design Cycle
Leveraging Formal Verification Throughout the Entire Design Cycle Verification Futures Page 1 2012, Jasper Design Automation Objectives for This Presentation Highlight several areas where formal verification
The C/C++ Memory Model: Overview and Formalization
The C/C++ Memory Model: Overview and Formalization Mark Batty Jasmin Blanchette Scott Owens Susmit Sarkar Peter Sewell Tjark Weber Verification of Concurrent C Programs C11 / C++11 In 2011, new versions
Processor (IV) - advanced ILP. Hwansoo Han
Processor (IV) - advanced ILP Hwansoo Han Instruction-Level Parallelism (ILP) Pipelining: executing multiple instructions in parallel To increase ILP Deeper pipeline Less work per stage shorter clock cycle
ILP concepts (2.1) Basic compiler techniques (2.2) Reducing branch costs with prediction (2.3) Dynamic scheduling (2.4 and 2.5)
Instruction-Level Parallelism and its Exploitation: PART 1 ILP concepts (2.1) Basic compiler techniques (2.2) Reducing branch costs with prediction (2.3) Dynamic scheduling (2.4 and 2.5) Project and Case
ECE/CS 552: Pipeline Hazards
ECE/CS 552: Pipeline Hazards Prof. Mikko Lipasti Lecture notes based in part on slides created by Mark Hill, David Wood, Guri Sohi, John Shen and Jim Smith Pipeline Hazards Forecast Program Dependences
Pragmatic Simulation-Based Verification of Clock Domain Crossing Signals and Jitter using SystemVerilog Assertions
Pragmatic Simulation-Based Verification of Clock Domain Crossing Signals and Jitter using SystemVerilog Assertions Mark Litterick (Verification Consultant) mark.litterick@verilab.com 2 Introduction Clock