Copyright © Bluespec Inc Bluespec SystemVerilog™ Design Example A DMA Controller with a Socket Interface

Copyright © Bluespec Inc Overview A DMA controller using Bluespec is presented Including several examples showing one possible refinement flow First model shows a simple 1 channel, 1 port model (222 lines) Final model shows a 2 channel, 2 port model, with pipelined and concurrent transactions (308 lines) Testbenches included for all models

Copyright © Bluespec Inc General Setup DMA Target master slave master Testbench

Copyright © Bluespec Inc DMA All DMA models contain a configuration port (slave), to read & write configuration and status registers One or two memory ports are included Configuration/Status registers Source and destination address register Transfer count Enable and current status Port selection

Copyright © Bluespec Inc File Organization DMA.bsv – The DMA model TestBench.bsv – The testbench sysTestBenchBench.out.expected – expected simulations results Socket_IFC.bsv – defines a simple socket protocol, interfaces, structures, and utility functions. EdgeFIFOs.bsv – some specialized FIFOs used throughout the designs Targets.bsv – A simple target module used for testing Makefile – usual

Copyright © Bluespec Inc Socket Interface We use a simple Socket interface which is similar to OCP Request and Responses are decoupled Several requests may be outstanding (pipelined)

Copyright © Bluespec Inc Socket Interface reqOp reqAddr reqData reqInfo reqAccept respOp respAddr respData respInfo respAccept Master interface Slave interface Request side Response side Target Initiator

Copyright © Bluespec Inc Socket_Ifc.bsv Defines structures for Request and Responses Interfaces for the Master and Slave typedef struct { RespOp respOp; RespInfo respInfo; RespAddr respAddr; RespData respData; } Socket_Resp interface Socket_master_req_ifc; method ReqOp getReqOp (); method ReqInfo getReqInfo (); method ReqAddr getReqAddr (); method ReqData getReqData (); method Action reqAccept (); endinterface

Copyright © Bluespec Inc Socket_Ifc.bsv Conversion functions from FIFO interfaces to Interface Utilities to connect Master and slave interface Convenience functions for debug function Socket_master_ifc fifos_to_master_ifc (FIFOF#(Socket_Req) reqs, FIFOF#(Socket_Resp) resps);

Copyright © Bluespec Inc Edge FIFOs Specialized FIFOs Pipeline FIFOs – a pipeline register with a FIFO interface. Bypass FIFOs – a 1 element FIFO which allows non-registered operations Unguarded versions – Disables Bluespec’s implicit conditions; needed for socket protocol to provide data every cycle

Copyright © Bluespec Inc Targets Contains just a “dummy” target to act like a “memory” for testing Minimum 2 cycle latency Slave requests responses Rules for Read and Write requests

Copyright © Bluespec Inc Model development details V0 – Simple FSM based DMA controller. 1 channel, 1 bus V1 – Rule-based DMA controller, allowing pipelined requests V2 – 2 Memory port, allowing pipelined concurrent read and write request V3 – Modified version of V2 showing Bluespec’s elaboration features V4 – 2 channels, 2 ports, concurrent and pipelined transactions

Copyright © Bluespec Inc V0 – simple DMA FSM Slave Config requests Config responses Rules for Read and Write config/status resisters Master mmu config Idle Write Finish Write Read Finish Non-idle arc write a mmu request or read a response Pipeline FIFO Bypass FIFO

Copyright © Bluespec Inc VO DMA behavior 8 cycles to move each word 2 cycle in memory 2 cycle in DMA (enqueue request, and grad data) cycle: 25 Target mem: Socket_Req{RD, 001, , }} cycle: 26 cycle: 27 cycle: 28 cycle: 29 Target mem: Socket_Req{WR, 002, , }} cycle: 30 cycle: 31 cycle: 32 cycle: 33 Target mem: Socket_Req{RD, 001, , }}

Copyright © Bluespec Inc V0 thoughts Most cycles are spent waiting for the mmu to respond Read requests cannot overlap with write requests V1 decouples all these activities Read and write requests start anytime one is needed (and all pre-conditions are met) Responses are taken and acted upon when they arrive.

Copyright © Bluespec Inc DMA V1 Each read request passes the write address to the write side via a FIFO Reads or Writes can start at any time rule startRead (dmaEnabledR && readCntrR > currentReadR ) ; let req = Socket_Req {reqAddr : readAddrR, reqData : 0, reqOp : RD, reqInfo : 1}; mmuReqF.enq( req ) ; // Enqueue the Write destination address destAddrF.enq( destAddrR ) ; // increment addresses, decrement the counter. readAddrR <= readAddrR + 1 ; currentReadR <= currentReadR + 1 ; destAddrR <= destAddrR + 1 ; endrule

Copyright © Bluespec Inc V1 DMA write rule Implicit conditions check FIFO states as needed Rule urgency puts writes before reads (* descending_urgency = "startWrite, startRead" *) rule startWrite ( True ) ; let wreq = Socket_Req {reqAddr : destAddrF.first, reqData : responseDataF.first, reqOp : WR, reqInfo : 2 }; // tag info with 2 // enqueue the request. mmuReqF.enq( wreq ) ; // remove wdata from the fifos destAddrF.deq ; responseDataF.deq ; endrule

Copyright © Bluespec Inc V1 Behavior Fully pipelined behavior Achieves maximum throughput - 2 cycles per word Target mem: Socket_Req{RD, 001, , }} cycle: 18 Target mem: Socket_Req{RD, 001, , }} cycle: 19 Target mem: Socket_Req{RD, 001, , }} cycle: 20 Target mem: Socket_Req{RD, 001, , }} cycle: 21 Target mem: Socket_Req{WR, 002, , }} cycle: 22 Target mem: Socket_Req{WR, 002, , }} cycle: 23 Target mem: Socket_Req{WR, 002, , }} cycle: 24 Target mem: Socket_Req{WR, 002, , }} cycle: 25 Target mem: Socket_Req{RD, 001, , }}

Copyright © Bluespec Inc V2 – A second memory port Port can be second memory, bus, or peripheral, separate read/write ports. Hardware additions: Second master interface to DMA New FIFOs for interface Configuration register to mark port Duplicated rules for each port Bluespec’s Rule analysis insures safe use of shared hardware – MMUs, FIFOs, etc. Muxes and control logic added automatically

Copyright © Bluespec Inc V2 DMA behavior Concurrent read and writes on different memories Peak throughput – 1 word per cycle Pipeline behavior maintained cycle: 23 Target memA: Socket_Req{WR, 002, , }} cycle: 24 Target memB: Socket_Req{RD, 001, , }} Target memA: Socket_Req{WR, 002, , }} cycle: 25 Target memB: Socket_Req{RD, 001, , }} Target memA: Socket_Req{WR, 002, , }} cycle: 26 Target memB: Socket_Req{RD, 001, , }} Target memA: Socket_Req{WR, 002, , }} cycle: 27 Target memB: Socket_Req{RD, 001, , }}

Copyright © Bluespec Inc V3 – Bluespec Elaboration Bluespec allow manipulation of most objects (e.g., Rules, FIFOs) during elaboration Reduces cut & paste code, allows better reuse V3 defines function to generate rules for each mmu port function Rules generatePortDMARules (Bool rdPortCond, Bool wrPortCond, FIFOF#(Socket_Req) requestF, FIFOF#(Socket_Resp) responseF );

Copyright © Bluespec Inc V3 Results Same behavior as V2 Real difference is about 26 lines of code out of 227 lines. Less than 10 % for a second mmu port.

Copyright © Bluespec Inc V4 – multiple channels Each channel is separate DMA engine – has it own read/write address, config/status registers, etc. V4 model changes constructs from scalar to vector, e.g. Rule generation function used to create second set of rule second channel Bluespec’s rules manages concurrency // The destination address registers Vector#(NumChannels,Reg#(ReqAddr)) destAddrRs <- replicateM( mkReg(0) );

Copyright © Bluespec Inc V4 Behavior Multiple channels, multiple ports, fully pipelined, concurrent reads and writes across channels Target memB: Socket_Req{RD, 000, , }} Target memA: Socket_Req{WR, 001, , }} cycle: 135 Target memB: Socket_Req{RD, 000, , }} Target memA: Socket_Req{RD, 002, , }} cycle: 136 Target memB: Socket_Req{WR, 003, , }} Target memA: Socket_Req{WR, 001, , }}

Copyright © Bluespec Inc Summary Concurrency automatically analyzed and control logic automatically synthesized 4 unique DMA architectures minimum development effort – compare lines of code Allow rapid exploration and analysis of different architectures V0V1V2V3V