Memory Consistency Verification of Hardware Yatin A. Manerkar - PowerPoint PPT Presentation

Memory Consistency Models (MCMs) Memory Consistency Models (MCMs) Specify rules and guarantees about the ordering and visibility of accesses to shared memory [Sorin et al., 2011]. … C11/ Java Cuda OpenCL C++11 Bytecode … LLVM IR JVM PTX SPIR … ARM Power x86 Nvidia AMD CPU CPU CPU GPU GPU Shared Virtual Memory

Memory Consistency Models (MCMs) Memory Consistency Models (MCMs) Specify rules and guarantees about the ordering and visibility of accesses to shared memory [Sorin et al., 2011]. SW MCMs … C11/ Java Cuda OpenCL C++11 Bytecode … LLVM IR JVM PTX SPIR … ARM Power x86 Nvidia AMD CPU CPU CPU GPU GPU Shared Virtual Memory

Memory Consistency Models (MCMs) Memory Consistency Models (MCMs) Specify rules and guarantees about the ordering and visibility of accesses to shared memory [Sorin et al., 2011]. … C11/ Java Cuda OpenCL C++11 Bytecode … LLVM IR JVM PTX SPIR HW MCMs … ARM Power x86 Nvidia AMD CPU CPU CPU GPU GPU Shared Virtual Memory

Memory Consistency Models (MCMs) Memory Consistency Models (MCMs) Specify rules and guarantees about the ordering and visibility of accesses to shared memory [Sorin et al., 2011]. … C11/ Java Cuda OpenCL C++11 Bytecode IR MCMs … LLVM IR JVM PTX SPIR … ARM Power x86 Nvidia AMD CPU CPU CPU GPU GPU Shared Virtual Memory

The Need for MCM Verification ▪ MCMs are specified at interfaces between layers of the stack • Upper layers target MCM; lower layers must maintain it for all programs! Upper layer (e.g. Compiler) Interface MCM (e.g. ISA-level MCM) Interface (e.g. ISA-Level MCM) Lower layer (e.g. Microarchitecture 1 ) 1 Microarchitecture is a component-level (e.g. caches, pipeline stages, store buffers) model of the hardware.

The Need for MCM Verification ▪ MCMs are specified at interfaces between layers of the stack • Upper layers target MCM; lower layers must maintain it for all programs! Targets MCM of Upper layer (e.g. Compiler) lower layer Interface MCM (e.g. ISA-level MCM) Interface (e.g. ISA-Level MCM) Lower layer (e.g. Microarchitecture 1 ) 1 Microarchitecture is a component-level (e.g. caches, pipeline stages, store buffers) model of the hardware.

The Need for MCM Verification ▪ MCMs are specified at interfaces between layers of the stack • Upper layers target MCM; lower layers must maintain it for all programs! Targets MCM of Upper layer (e.g. Compiler) lower layer Interface (e.g. ISA-Level MCM) Must maintain MCM of interface! Lower layer (e.g. Microarchitecture 1 ) 1 Microarchitecture is a component-level (e.g. caches, pipeline stages, store buffers) model of the hardware.

The Need for MCM Verification ▪ MCMs are specified at interfaces between layers of the stack • Upper layers target MCM; lower layers must maintain it for all programs! Targets MCM of Upper layer (e.g. Compiler) lower layer ??? Must maintain MCM of interface! Lower layer (e.g. Microarchitecture 1 ) 1 Microarchitecture is a component-level (e.g. caches, pipeline stages, store buffers) model of the hardware.

The Check Suite: Automated Tools For Verifying Memory Orderings and their Security Implications High-Level Languages (HLL) TriCheck [ASPLOS ‘17] [IEEE MICRO Top Picks] CheckMate Compiler OS [Micro ‘18] COATCheck [ASPLOS ‘16] [IEEE MICRO Top Picks] [IEEE Micro Top Picks] Architecture (ISA) PipeCheck [Micro ‘14] [IEEE MICRO Top Picks] PipeProof Microarchitecture CCICheck [Micro ‘15] [Nominated for Best Paper Award] [Micro ‘18] RTLCheck [Micro ‘17] [IEEE MICRO Top Picks Honorable Mention] [Best Paper Nominee. RTL (e.g. Verilog) IEEE Micro Top Picks Honorable Mention] A B • Axiomatic specifications -> Happens-before graphs C • Cyclic => Impossible, Acyclic => Possible • Model Checking space of graphs using SMT solvers • Most tools written in Gallina => can be proven correct http://check.cs.princeton.edu

The Check Suite: Automated Tools For Verifying Memory Orderings and their Security Implications High-Level Languages (HLL) TriCheck [ASPLOS ‘17] [IEEE MICRO Top Picks] CheckMate Compiler OS [Micro ‘18] COATCheck [ASPLOS ‘16] [IEEE MICRO Top Picks] [IEEE Micro Top Picks] Architecture (ISA) PipeCheck [Micro ‘14] [IEEE MICRO Top Picks] PipeProof Microarchitecture CCICheck [Micro ‘15] [Nominated for Best Paper Award] [Micro ‘18] RTLCheck [Micro ‘17] [IEEE MICRO Top Picks Honorable Mention] [Best Paper Nominee. RTL (e.g. Verilog) IEEE Micro Top Picks So far, tools have found bugs in: Honorable Mention] A • Widely-used Research simulator • B Cache coherence paper • Axiomatic specifications -> Happens-before graphs • IBM XL C++ compiler (fixed in v13.1.5) C • Cyclic => Impossible, Acyclic => Possible • In-design commercial processors • Model Checking space of graphs using SMT solvers • RISC-V ISA specification • Open-source RTL (Verilog) • Most tools written in Gallina => can be proven correct • C++ 11 mem model http://check.cs.princeton.edu • SpectrePrime, MeltdownPrime

Talk Outline ▪ Overview and Motivation ▪ Memory Consistency Background ▪ PipeProof: All-Program Microarchitectural MCM Verification ▪ RTLCheck: MCM Verification of Verilog RTL ▪ Expanding to other domains ▪ Conclusion 14

Microarchitectural MCM Verification Mic icroarchit itecture ... Core 0 Core n IF IF ? ... EX EX SC/TSO/RISC-V MCM? WB WB Memory Hierarchy ▪ PipeProof proves that a microarchitecture respects its ISA MCM • For all possible programs! ▪ How do we formally specify • ISA-level MCMs? • Microarchitectural orderings?

ISA-Level MCM Specifications Message passing (mp) litmus test ▪ MCMs often defined using relational patterns Core 0 Core 1 • [Shasha and Snir TOPLAS 1988] [Alglave et al. TOPLAS 2014] (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; ▪ ISA-level executions are graphs SC Forbids: r1 = 1, r2 = 0 • nodes: instructions, edges: ISA-level relations ▪ Eg: SC is 𝑏𝑑𝑧𝑑𝑚𝑗𝑑 𝑞𝑝 ∪ 𝑑𝑝 ∪ 𝑠𝑔 ∪ 𝑔𝑠 Legend: fr po = Program order co = coherence order po rf po rf = reads-from (i1) (i2) (i3) (i4) fr = from-reads ▪ Formal specifications of ISA + HLL MCMs in recent years • x86 [Owens et al. TPHOLS2009] , ARM [Pulte et al. POPL2018] , C11 [Batty et al. POPL 2011] , … ▪ Automated formal tools e.g. herd [Alglave et al. TOPLAS 2014] • Can formally analyse small test programs against these models 16

Microarchitectural Happens-Before (µhb) Graphs Message passing (mp) litmus test ▪ Developed by PipeCheck [Lustig et al. MICRO 2014] Core 0 Core 1 ▪ Microarchitecture performs instrs. in stages (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; ▪ Microarchitectural executions are µhb graphs SC Forbids: r1 = 1, r2 = 0 • Nodes: instr. sub-events, edges: happens-before relationships ▪ Cyclic µhb graph → unobservable , Acyclic → observable fr simpleSC microarchitecture po ... rf po Core 0 Core n (i1) (i2) (i3) (i4) IF IF ... EX EX WB WB Legend: IF = Fetch EX = Execute Memory Hierarchy WB = Writeback 17

Microarchitectural Happens-Before (µhb) Graphs Message passing (mp) litmus test ▪ Developed by PipeCheck [Lustig et al. MICRO 2014] Core 0 Core 1 ▪ Microarchitecture performs instrs. in stages (i1) x = 1; (i3) r1 = y; (i2) y = 1; (i4) r2 = x; ▪ Microarchitectural executions are µhb graphs SC Forbids: r1 = 1, r2 = 0 • Nodes: instr. sub-events, edges: happens-before relationships ▪ Cyclic µhb graph → unobservable , Acyclic → observable fr simpleSC microarchitecture po ... rf po Core 0 Core n (i1) (i2) (i3) (i4) IF IF IF ... EX EX EX WB WB Legend: IF = Fetch EX = Execute WB Memory Hierarchy WB = Writeback 17

Microarchitectural MCM Verification Mic icroarchit itecture ... Core 0 Core n IF IF ? ... EX EX SC/TSO/RISC-V MCM? WB WB Memory Hierarchy

Microarchitectural MCM Verification Mic icroarchit itecture Speci cific icati tion in in μSpec DS DSL ... Axiom "PO_Fetch": Core 0 Core n forall microops "i1", IF IF forall microops "i2", ? ... SameCore i1 i2 /\ ProgramOrder i1 i2 => EX EX AddEdge ((i1, Fetch), (i2, Fetch), "PO"). SC/TSO/RISC-V MCM? WB WB Axiom "Execute_stage_is_in_order": forall microops "i1", Memory Hierarchy ... ▪ µSpec DSL [Lustig et al. ASPLOS 2016] is similar to first-order logic (FOL) • forall , exists , AND ( /\ ), OR ( \/ ), NOT ( ~ ), implication ( => ) • Has built-in predicates which take memory operations as input − e.g. ProgramOrder i j where i and j are loads/stores • Predicates can reference nodes and edges (µhb edges closed under transitivity) − e.g. EdgeExists ((i1, Fetch), (i2, Fetch))

PipeProof: Automated All-Program MCM Verif. ▪ PipeProof verifies that a microarchitecture correctly High-Level Languages (HLL) respects its ISA MCM across all possible programs • Early-stage design-time verification (i.e. before RTL) Compiler Microarch. and Aux. Inputs ISA MCM Specs (e.g. Mappings) Instruction Set (ISA) Microarchitecture PipeProof Processor RTL (Verilog) All-Program MCM Correctness Proof! [ Yatin A. Manerkar , Daniel Lustig, Margaret Martonosi, and Aarti Gupta. PipeProof: Automated Memory Consistency Proofs for 19 Microarchitectural Specifications. The 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), October 2018.]

Verifying Across All Possible Programs ▪ Are all forbidden programs microarchitecturally unobservable? • If so, then microarchitecture is correct ▪ Infinite number of forbidden programs • E.g.: For SC, must check all possibilities of 𝑑𝑧𝑑𝑚𝑗𝑑(𝑞𝑝 ∪ 𝑑𝑝 ∪ 𝑠𝑔 ∪ 𝑔𝑠) ▪ Prove using abstractions and induction • Based on Counterexample-guided abstraction refinement [Clarke et al. CAV 2000] 20

Verifying Across All Possible Programs ▪ Are all forbidden programs microarchitecturally unobservable? • If so, then microarchitecture is correct ▪ Infinite number of forbidden programs • E.g.: For SC, must check all possibilities of 𝑑𝑧𝑑𝑚𝑗𝑑(𝑞𝑝 ∪ 𝑑𝑝 ∪ 𝑠𝑔 ∪ 𝑔𝑠) ▪ Prove using abstractions and induction • Based on Counterexample-guided abstraction refinement [Clarke et al. CAV 2000] fr fr po co … i 1 i 2 i 3 co po rf i 1 i 2 i 3 i 4 rf co po i 1 i 2 po po rf i 1 i 2 i 3 i 4 20

The Transitive Chain (TC) Abstraction All non-unary cycles containing fr ( Infinite set ) fr po co i 1 i 2 i 3 fr fr po po rf po i 1 i 2 i 3 i 4 i 1 i 2 po … fr co rf i 1 i 2 i 3 i 4 21

The Transitive Chain (TC) Abstraction All non-unary cycles containing fr ( Infinite set ) fr po co i 1 i 2 i 3 fr fr po po rf po i 1 i 2 i 3 i 4 i 1 i 2 po … fr co rf i 1 i 2 i 3 i 4 Cycle = Transitive Chain (sequence) + Loopback edge (fr) 21

The Transitive Chain (TC) Abstraction All non-unary cycles containing fr Transitive chain (sequence) ( Infinite set ) of ISA-level edges fr fr po co r 1…n -1 i 1 i 2 i 3 i 1 i n fr fr po po rf po i 1 i 2 i 3 i 4 i 1 i 2 po … fr co rf i 1 i 2 i 3 i 4 Cycle = Transitive Chain (sequence) + Loopback edge (fr) 21

The Transitive Chain (TC) Abstraction All non-unary cycles containing fr ( Infinite set ) fr fr po co r 1…n -1 i 1 i 2 i 3 i 1 i n IF fr fr Some µhb edge from i 1 po po rf po i 1 i 2 i 3 i 4 i 1 i 2 EX to i n po … (transitive fr connection) WB co rf i 1 i 2 i 3 i 4 Cycle = Transitive Chain (sequence) ISA-level transitive chain => + Loopback edge (fr) Microarch. level transitive connection 21

The Transitive Chain (TC) Abstraction Infinite! fr po co i 1 i 2 i 3 fr po po rf i 1 i 2 i 3 i 4 fr po co rf i 1 i 2 i 3 i 4 fr po … i 1 i 2 22

The Transitive Chain (TC) Abstraction Infinite! Finite! fr fr po co i 1 i 2 i 3 r 1…n -1 i 1 i n fr IF Using Some µhb po po rf ⟹ edge from i 1 TC Abstraction i 1 i 2 i 3 i 4 EX to i n (transitive fr connection) WB po co rf i 1 i 2 i 3 i 4 fr 3 x 3 = 9 possible transitive connections po … i 1 i 2 from i 1 to i n 22

The Transitive Chain (TC) Abstraction Infinite! Finite! fr fr fr fr i 1 i n i 1 i n i 1 i n IF IF IF po co i 1 i 2 i 3 EX EX EX WB WB WB fr Using po po rf fr fr fr ⟹ i 1 i 1 i 1 i n i n i n TC Abstraction i 1 i 2 i 3 i 4 IF IF IF fr EX EX EX po WB WB WB co rf i 1 i 2 i 3 i 4 fr fr fr i 1 i n i 1 i n i 1 i n fr IF IF IF po … EX EX EX i 1 i 2 WB WB WB 22

The Transitive Chain (TC) Abstraction Infinite! Finite! fr Abstraction soundness fr fr fr i 1 i n i 1 i n i 1 i n IF IF IF automatically verified po co i 1 i 2 i 3 as a supporting proof! EX EX EX WB WB WB fr Using po po rf fr fr fr ⟹ i 1 i 1 i 1 i n i n i n TC Abstraction i 1 i 2 i 3 i 4 IF IF IF fr EX EX EX po WB WB WB co rf i 1 i 2 i 3 i 4 fr fr fr i 1 i n i 1 i n i 1 i n fr IF IF IF po … EX EX EX i 1 i 2 WB WB WB 22

Microarchitectural Correctness Proof Cycles containing fr fr i 1 i n All possible Some µhb transitive edge from connections i 1 to i n (transitive connection) Cycles containing po po i 1 i n Some µhb edge from i 1 to i n (transitive connection) Other ISA-level cycles… 23

Microarchitectural Correctness Proof fr ✓ NoDecomp Cycles containing fr i 1 i n fr IF i 1 i n All possible Some µhb transitive EX edge from connections i 1 to i n (transitive WB connection) Cycles containing po po i 1 i n Some µhb edge from i 1 to i n (transitive connection) Other ISA-level Other transitive cycles… connections… 23

Microarchitectural Correctness Proof fr ✓ NoDecomp Cycles containing fr i 1 i n fr IF i 1 i n All possible Some µhb transitive EX edge from connections i 1 to i n (transitive WB connection) fr ? AbsCounterX Cycles containing po i 1 i n po IF i 1 i n Acyclic graph with transitive connection => Some µhb EX Abstract Counterexample (i.e. possible bug) edge from i 1 to i n WB (transitive connection) Other ISA-level Other transitive cycles… connections… 23

Microarchitectural Correctness Proof fr ✓ NoDecomp Cycles containing fr Transitive connection (green edge) may i 1 i n fr IF i 1 i n represent one or multiple ISA-level edges All possible Some µhb transitive EX edge from connections i 1 to i n (transitive WB connection) fr ? AbsCounterX Cycles containing po i 1 i n po IF i 1 i n Some µhb EX edge from i 1 to i n WB (transitive connection) Other ISA-level Other transitive cycles… connections… 23

Microarchitectural Correctness Proof fr ✓ NoDecomp Cycles containing fr Transitive connection (green edge) may i 1 i n fr IF i 1 i n represent one or multiple ISA-level edges All possible Some µhb transitive EX edge from connections i 1 to i n (transitive WB connection) fr ? AbsCounterX Cycles containing po i 1 i n po IF i 1 i n Try to Concretize (Replace transitive connection Some µhb EX with one ISA-level edge) edge from i 1 to i n Observable WB (transitive connection) Other ISA-level Other transitive Microarch Buggy, cycles… connections… Return Counterexample 23

Microarchitectural Correctness Proof fr ✓ NoDecomp Cycles containing fr Transitive connection (green edge) may i 1 i n fr IF i 1 i n represent one or multiple ISA-level edges All possible Some µhb transitive EX edge from connections i 1 to i n (transitive WB connection) fr ? AbsCounterX Cycles containing po i 1 i n po IF Consider all i 1 i n Try to Concretize (Replace Unobs. Decompositions transitive connection Some µhb (Inductively break EX with one ISA-level edge) edge from down Transitive Chain) i 1 to i n Observable WB (transitive connection) Other ISA-level Other transitive Microarch Buggy, cycles… connections… Return Counterexample 23

Microarchitectural Correctness Proof fr ✓ NoDecomp Cycles containing fr Transitive connection (green edge) may i 1 i n fr IF i 1 i n represent one or multiple ISA-level edges All possible Some µhb transitive EX edge from connections i 1 to i n “Refinement Loop” (transitive WB connection) fr ? AbsCounterX Cycles containing po i 1 i n po IF Consider all i 1 i n Try to Concretize (Replace Unobs. Decompositions transitive connection Some µhb (Inductively break EX with one ISA-level edge) edge from down Transitive Chain) i 1 to i n Observable WB (transitive connection) Other ISA-level Other transitive Microarch Buggy, cycles… connections… Return Counterexample 23

Refinement Loop: Concretization ▪ Replaces transitive connection with a single ISA-level edge • All concretizations must be unobservable • Observable concretizations are counterexamples (bugs) fr ? AbsCounterX i 1 i n IF EX WB 24

Refinement Loop: Concretization ▪ Replaces transitive connection with a single ISA-level edge • All concretizations must be unobservable • Observable concretizations are counterexamples (bugs) fr rf i 1 i n IF EX WB 24

Refinement Loop: Concretization ▪ Replaces transitive connection with a single ISA-level edge • All concretizations must be unobservable • Observable concretizations are counterexamples (bugs) po … fr fr rf i 1 i n i 1 i n IF IF EX EX WB WB 24

Refinement Loop: Decomposition ▪ Inductively break down transitive chain • Additional constraints may be enough to make execution unobservable factorial(n) = factorial(n-1) * n fr ? AbsCounterX i n i 1 IF EX r p q WB 25

Refinement Loop: Decomposition ▪ Inductively break down transitive chain • Additional constraints may be enough to make execution unobservable factorial(n) = factorial(n-1) * n Chain of length n = Chain of length n-1 + “Peeled - off” edge fr ? AbsCounterX i n i 1 IF EX r p q WB 25

Refinement Loop: Decomposition ▪ Inductively break down transitive chain • Additional constraints may be enough to make execution unobservable factorial(n) = factorial(n-1) * n Chain of length n = Chain of length n-1 + “Peeled - off” edge fr fr rf i n i 1 i 1 i n-1 i n IF IF EX EX r r s p p q q WB WB ✓ 25

Refinement Loop: Decomposition ▪ Inductively break down transitive chain • Additional constraints may be enough to make execution unobservable factorial(n) = factorial(n-1) * n Chain of length n = Chain of length n-1 + “Peeled - off” edge fr fr fr rf co … i n i 1 i 1 i n-1 i n i 1 i 2 i n IF IF IF EX EX r r r EX s WB p p q q p t q WB WB ✓ 25

Refinement Loop: Decomposition ▪ Inductively break down transitive chain • Additional constraints may be enough to make execution unobservable factorial(n) = factorial(n-1) * n Chain of length n = Chain of length n-1 + “Peeled - off” edge fr fr fr rf co … i n i 1 i 1 i n-1 i n i 1 i 2 i n IF IF IF If decomposition is abstract EX EX r r r EX counterexample, repeat concretization and decomposition! s WB p p q q p t q WB WB ✓ ? 25

Results ▪ Ran PipeProof on simpleSC (SC) and simpleTSO (TSO 1 ) µarches • 3-stage in-order pipelines ▪ TSO verification made feasible by optimizations • Explicitly checking all decompositions => case explosion • Covering Sets Optimization (eliminate redundant transitive connections) • Memoization (eliminate previously checked ISA-level cycles) simpleSC simpleSC (w/ Covering Sets + Memoization) Total Time 225.9 sec 19.1 sec simpleTSO simpleTSO (w/ Covering Sets + Memoization) Total Time Timeout 2449.7 sec (≈ 41 mins) 26 1 TSO (Total Store Order) is the MCM of Intel x86 processors. It relaxes Store->Load ordering.

PipeProof Takeaways ▪ First Ever Automated All-Program Microarchitectural MCM Verification • Designers get both completeness and automation of verification • Engineers can verify microarchitectures themselves, before RTL is written! ▪ Based on techniques from formal methods (CEGAR) [Clarke et al. CAV 2000] ▪ Transitive Chain (TC) Abstraction models infinite set of executions ▪ Accolades: • Nominated for Best Paper at MICRO 2018 • “Honorable Mention” in 2018 IEEE Micro Top Picks of Comp. Arch. Conferences 27

Talk Outline ▪ Overview and Motivation ▪ Memory Consistency Background ▪ PipeProof: All-Program Microarchitectural MCM Verification ▪ RTLCheck: MCM Verification of Verilog RTL ▪ Expanding to other domains ▪ Conclusion 28

What if I want to verify RTL (Verilog)? ISA-Level MCM fr acyclic (po U co U rf U fr) po rf po i 1 i 2 i 3 i 4 Verified with Microarchitectural Orderings PipeProof (i1) (i2) (i3) (i4) Axiom "PO_Fetch": IF forall microop "i1", "i2", EX SameCore i1 i2 /\ ProgramOrder i1 i2 => AddEdge ((i1, IF), (i2, IF)). WB ... 29

What if I want to verify RTL (Verilog)? ISA-Level MCM fr acyclic (po U co U rf U fr) po rf po i 1 i 2 i 3 i 4 Verified with Microarchitectural Orderings PipeProof (i1) (i2) (i3) (i4) Axiom "PO_Fetch": IF forall microop "i1", "i2", EX SameCore i1 i2 /\ ProgramOrder i1 i2 => AddEdge ((i1, IF), (i2, IF)). WB ... ? RTL implementation (Verilog) 29 [RTL Image: Christopher Batten]

What if I want to verify RTL (Verilog)? ISA-Level MCM fr acyclic (po U co U rf U fr) po rf po i 1 i 2 i 3 i 4 Verified with Microarchitectural Orderings ✓ PipeProof (i1) (i2) (i3) (i4) Axiom "PO_Fetch": IF forall microop "i1", "i2", EX SameCore i1 i2 /\ ProgramOrder i1 i2 => AddEdge ((i1, IF), (i2, IF)). WB ...  ? RTL implementation (Verilog) 29 [RTL Image: Christopher Batten]

RTLCheck: Checking RTL Consistency Orderings ▪ RTLCheck enables automated checking of Verilog RTL High-Level Languages (HLL) against µspec axioms for litmus test suites µspec axioms Litmus Test Axiom "PO_Fetch": Core 0 Core 1 Compiler Mapping forall microop "i1", "i2", x = 1; r1 = y; SameCore i1 i2 /\ ProgramOrder i1 i2 => Functions y = 1; r2 = x; AddEdge ((i1, IF), (i2, IF)). Instruction Set (ISA) RTLCheck Microarchitecture Processor RTL (Verilog) assert property @(posedge clk) (...) ... Test-specific Temporal RTL Properties [ Yatin A. Manerkar , Daniel Lustig, Margaret Martonosi, and Michael Pellauer. RTLCheck: Verifying the Memory Consistency of RTL Designs. 30 The 50th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), October 2017.]

SystemVerilog Assertions (SVA) ▪ SVA: Industry standard for RTL verification, e.g.: ARM [Reid et al. CAV 2016] • Based on Linear Temporal Logic (LTL) with regular operators ▪ Commercial tools (e.g. JasperGold) can formally verify SVA assertions ▪ Translating µspec to SVA => RTL MCM verification using industry flows ▪ But it’s not that simple! SVA Assertions assert property @(posedge clk) (...) RTL Impl. ... Cadence JasperGold Assertion Proven? Counterexample found? 31

Meaning can be Lost in Translation! 小心地滑 (Caution: Slippery Floor)

Memory Consistency Verification of Hardware Yatin A. Manerkar - PowerPoint PPT Presentation

Automated Formal Memory Consistency Verification of Hardware Yatin A. Manerkar Princeton University June 23 rd , 2019 http:/ ://www.c .cs.p .princeton.edu/~manerkar 1 The Rise of Parallelism 2 [Image: K. Rupp, M. Horowitz et al.] The

Software verification under weak memory consistency Viktor Vafeiadis Max Planck Institute for

Memory Consistency Models CSE 451 James Bornholt Memory consistency models The short version:

Verification with the Check suite Yatin Manerkar Princeton University ARM Cambridge, July 20 th ,

CSC2/458 Parallel and Distributed Systems Parallel Memory Systems Consistency Sreepathi Pai

C++ 11 Memory Consistency Model Sebastian Gerstenberg NUMA Seminar 07.01.2015 Agenda 1.

Distributed Memory and Cache Consistency Distributed Memory and Cache Consistency (some slides

Distributed Memory and Cache Consistency Distributed Memory and Cache Consistency (some slides

Todays Topics - Distributed Shared Memory The Shared Memory Abstraction, why? Approaches

Shared Memory Consistency Models: A Tutorial By Sarita Adve, Kourosh Gharachorloo WRL

Distributed Shared Memory Distributed Shared Memory Systems Page based

Memory Consistency Don Porter 1 CSE 506: Opera.ng Systems Logical Diagram Binary Memory

An introduction to weak memory consistency and the out-of-thin-air problem Viktor Vafeiadis Max

Memory consistency in C++ Computer Architecture J. Daniel Garca Snchez (coordinator) David

CSL 860: Modern Parallel Computation Computation MEMORY CONSISTENCY Intuitive Memory Model

Memory Consistency Models Adam Wierman Daniel Neill Adve, Pai, and Ranganathan. Recent advances

Lecture 27: Pot-Pourri Todays topics: Consistency Models Shared memory vs

Memory consistency models Computer Architecture J. Daniel Garca Snchez (coordinator) David

Replication and Consistency Setting: Concurrent threads accessing shared data Roland Meyer (TU

Web Cache Consistency Web Cache Consistency Web Cache Consistency Web Cache Consistency

A Consistency Checker for Memory Subsystem Traces Matthew Naylor , Simon Moore, Alan Mujumdar

Outline Cache coherence the hardware view 1 2 Synchronization and memory consistency review 3

COMP 633 - Parallel Computing Lecture 12 September 17, 2020 CC-NUMA (2) Memory Consistency

Multiple- -Writer Distributed Memory Writer Distributed Memory Multiple The Sequential

PipeProof: Automated Memory Consistency Proofs for Microarchitectural Specifications Yatin A.