/
Computation Structures Group Computation Structures Group

Computation Structures Group - PowerPoint Presentation

faustina-dinatale
faustina-dinatale . @faustina-dinatale
Follow
344 views
Uploaded On 2019-03-02

Computation Structures Group - PPT Presentation

MITs RISCY Expedition Andy Wright Sizhuo Zhang Thomas Bourgeat Amol Bhave Jamey Hicks Arvind Computer Science amp Artificial Intelligence Lab Massachusetts Institute of Technology ID: 754654

consistency memory formal instruction memory consistency instruction formal risc riscy verified model verification vat asic store buffer htif weak

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "Computation Structures Group" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

Computation Structures GroupMIT’s RISCY ExpeditionAndy Wright, Sizhuo Zhang, Thomas Bourgeat, Amol Bhave, Jamey Hicks, ArvindComputer Science & Artificial Intelligence Lab.Massachusetts Institute of TechnologyRISC V Workshop, Redwood Shores, CAJanuary 6, 2015

1Slide2

IntroductionWe made an 64-bit RISC-V processorIMAFD extensionsMachine, Supervisor, and User modesBoots RISC-V Linux with Sv39 Paged Virtual MemoryTandem verified with SpikeWritten in Bluespec System VerilogWe are using this as a base for our “Riscy Expedition”2Slide3

Riscy ExpeditionFormal specification of the ISA using an operational modelFormally verified processor implementationsMemory Consistency ModelsShould RISC V have a weak memory model? Which memory model?AcceleratorsMicroarchitecture explorationVLSI implementations using standard ASIC flow – “push button” synthesisProcessors tuned for ASIC designs3Slide4

Verified DesignOur Philosophy: Get a working processor first, figure out why it is slow, and make it faster without breaking itThere is no separation of Design and Verification – There’s just verified designCurrently we are using Tandem Verification*In our expedition we are moving to Formal Verification4* Technology developed by Bluespec IncSlide5

Tandem verificationSpikeRiscyFpga

HTIF

HTIF

 

S contains :

The pc at step n.

The instruction executed at step n

The operands and the concerned registers

The packets exchanged with HTIF, if exists

The memory operations wanted to be performed, if exists

Jmp

a;

Jmp

a;

pc

pc

Very useful but for

highly-parameterized

designs it provides only a weak sense of correctness

5

SynchronizedSlide6

Formal Verification and SpecificationFormal Verification is constructing a proof that a processor matches a formal specificationBut we need a formal specification for RISC-VIn the ISA there are lots of (odd) cases that need to be specified for a formal verificationAre referenced bits in page table entries set for speculatively accessed pages?A single instruction can result in up to 13 effective memory accesses. How exactly do they interact with each other?How does they influence the memory model?6Slide7

Memory Consistency ModelStrong consistency models (e.g. SC, TSO)Easy to understand, but restricts optimizationsWeak consistency modelsPermit HW optimizations, but difficult to understandRelease Consistency (RC)Defined with “operation performed with respect to certain processor”Power/ARMDefinition in official ISA is not clearGeneral description: no ordering should be assumedSpecial cases where ordering is enforcedDependent loads cannot be reordered7Slide8

We want Simple operational definitionsLegal behaviors must be observable on a simple abstract machine consisting of cores and a shared monolithic memoryCores execute one instruction at a time in program orderMay have local buffers, like the store buffer used to define TSO; useful in modeling implicit reordering of memory instructions The effect of Fence instructions is to flush local buffersMulti-ported monolithic memory which processes one read or write immediately8Slide9

WMM: A new weak consistency modelWMM is defined using a store buffer and an invalidation buffer per corePermits all load-store reorderings except stores overtaking loadsAllows almost all microarchitectural optimizationsout-of-order executionmemory dependency speculationload-value speculationProvides an easy to understand operational model between cores9Slide10

“Flavored” Memory AccessesInst. Fetch

Mem.

Exec.

TLB

TLB

Instruction Fetch (I)

Virtual Address Translation (VAT)

Data Access (D)

Input/Output

(IO)

10

This looks like 4 separate cores accessing the same memorySlide11

Flavored Memory SynchronizationSFENCE.VMD.ST < SFENCE.VM < VAT.LDVAT.LD must see result of D.STWith this specification, some SFENCE.VMs are missing from the Linux kernelNo instruction for the other direction (yet)VAT.ST < ? < D.LDSo does D.LD always need to see the results of all previous VAT.STs immediately?We are looking at these flavored accesses closely and incorporating them into the memory model11Slide12

Further WorkAcceleratorsConvolutional Neural Network accelerator in BlueDBMMicroarchitectureOut-of-order execution multicore processorASIC ImplementationProcessor building blocks tuned for ASIC performance12Slide13

Questions?Contact information:Andy Wright – acwright@mit.educsg.csail.mit.edu/riscy-e13