Stmt FSM Arvind (with the help of Nirav Dave)

Slides:



Advertisements
Similar presentations
Elastic Pipelines and Basics of Multi-rule Systems Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology February.
Advertisements

An EHR based methodology for Concurrency management Arvind (with Asif Khan) Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology.
March 2007http://csg.csail.mit.edu/arvindSemantics-1 Scheduling Primitives for Bluespec Arvind Computer Science & Artificial Intelligence Lab Massachusetts.
Executes a statement or statements for a number of times – iteration. Syntax for(initialize; test; increment) { // statements to be executed } Initial.
Stmt FSM Richard S. Uhler Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology (based on a lecture prepared by Arvind)
Asynchronous Pipelines: Concurrency Issues Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology October 13, 2009http://csg.csail.mit.edu/koreaL12-1.
February 21, 2007http://csg.csail.mit.edu/6.375/L07-1 Bluespec-4: Architectural exploration using IP lookup Arvind Computer Science & Artificial Intelligence.
March, 2007http://csg.csail.mit.edu/arvindIPlookup-1 IP Lookup Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology.
September 24, L08-1 IP Lookup: Some subtle concurrency issues Arvind Computer Science & Artificial Intelligence Lab.
IP Lookup: Some subtle concurrency issues Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology February 22, 2011L06-1.
IP Lookup: Some subtle concurrency issues Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology March 4, 2013
December 10, 2009 L29-1 The Semantics of Bluespec Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute.
Computer Architecture: A Constructive Approach Sequential Circuits Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
December 12, 2006http://csg.csail.mit.edu/6.827/L24-1 Scheduling Primitives for Bluespec Arvind Computer Science & Artificial Intelligence Lab Massachusetts.
September 3, 2009L02-1http://csg.csail.mit.edu/korea Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial.
Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
BSV 1 for ESL 2 Design Rishiyur S. Nikhil, PhD. CTO, Bluespec, Inc. © Bluespec, Inc., 2008 Lecture in 6.375, MIT March 10, : Bluespec SystemVerilog.
Multiple Clock Domains (MCD) Continued … Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology November.
March, 2007Intro-1http://csg.csail.mit.edu/arvind Design methods to facilitate rapid growth of SoCs Arvind Computer Science & Artificial Intelligence Lab.
March 6, 2006http://csg.csail.mit.edu/6.375/L10-1 Bluespec-4: Rule Scheduling and Synthesis Arvind Computer Science & Artificial Intelligence Lab Massachusetts.
Constructive Computer Architecture: Guards Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology September 24, 2014.
September 22, 2009http://csg.csail.mit.edu/koreaL07-1 Asynchronous Pipelines: Concurrency Issues Arvind Computer Science & Artificial Intelligence Lab.
Constructive Computer Architecture Sequential Circuits Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology
Elastic Pipelines: Concurrency Issues Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology February 28, 2011L08-1http://csg.csail.mit.edu/6.375.
Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
Constructive Computer Architecture Sequential Circuits - 2 Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
1 Tutorial: Lab 4 Again Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology.
Modular Refinement Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology March 8,
October 22, 2009http://csg.csail.mit.edu/korea Modular Refinement Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology.
Non-blocking Caches Arvind (with Asif Khan) Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology May 14, 2012L25-1
Realistic Memories and Caches – Part III Li-Shiuan Peh Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology April 4, 2012L15-1.
Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
Multiple Clock Domains (MCD) Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology.
October 20, 2009L14-1http://csg.csail.mit.edu/korea Concurrency and Modularity Issues in Processor pipelines Arvind Computer Science & Artificial Intelligence.
October 6, 2009http://csg.csail.mit.edu/koreaL10-1 IP Lookup-2: The Completion Buffer Arvind Computer Science & Artificial Intelligence Lab Massachusetts.
Introduction to Bluespec: A new methodology for designing Hardware
Introduction to Bluespec: A new methodology for designing Hardware
Functions and Types in Bluespec
Concurrency properties of BSV methods and rules
Bluespec-6: Modeling Processors
Folded “Combinational” circuits
Scheduling Constraints on Interface methods
Sequential Circuits - 2 Constructive Computer Architecture Arvind
Sequential Circuits Constructive Computer Architecture Arvind
Sequential Circuits: Constructive Computer Architecture
IP Lookup: Some subtle concurrency issues
Stmt FSM Arvind (with the help of Nirav Dave)
Pipelining combinational circuits
Multirule Systems and Concurrent Execution of Rules
Bluespec-1: Design Affects Everything
Constructive Computer Architecture: Guards
Sequential Circuits Constructive Computer Architecture Arvind
Pipelining combinational circuits
Modular Refinement Arvind
Modular Refinement Arvind
BSV objects and a tour of known BSV problems
Bluespec-4: Architectural exploration using IP lookup Arvind
Modules with Guarded Interfaces
Pipelining combinational circuits
Sequential Circuits - 2 Constructive Computer Architecture Arvind
Introduction to Bluespec: A new methodology for designing Hardware
IP Lookup Arvind Computer Science & Artificial Intelligence Lab
IP Lookup: Some subtle concurrency issues
Constructive Computer Architecture: Guards
Introduction to Bluespec: A new methodology for designing Hardware
IP Lookup: Some subtle concurrency issues
Modular Refinement Arvind
Implementing for Correct Concurrency
Modular Refinement Arvind
Caches-2 Constructive Computer Architecture Arvind
Presentation transcript:

Stmt FSM Arvind (with the help of Nirav Dave) Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology

Motivation Some common design patterns are tedious to express in BSV Testbenchs Sequential machines (FSMs) especially sequential looping structures These are tedious to express in Verilog as well (but not in C) http://csg.csail.mit.edu/6.375 March 10, 2010

Testing the IP Lookup Design done? RAM fifo enter getResult outQ cbuf yes no getToken Input: IP Address Output: Route Value Need to test many different input/output sequences http://csg.csail.mit.edu/6.375 March 10, 2010

Testing IP Lookup Call many streams of requests responses from the device under test (DUT) Check correct with 1 request at a time Check correct with 2 concurrent requests Case 1 dut.enter(17.23.12.225) dut.getResult() dut.enter(17.23.12.25) Case 2 dut.enter(128.30.90.124) dut.enter(128.30.90.126) dut.getResult() http://csg.csail.mit.edu/6.375 March 10, 2010

But we usually want more counters, display, ... function Action makeReq(x); action reqCnt <= reqCnt + 1; dut.enter(x); $display(“[Req #: ”,fshow(reqCnt),“] = ”,fshow(x)); endaction endfunction function Action getResp(); resCnt <= resCnt + 1; let x <- dut.getResult(); $display(“[Rsp #:”,fshow(resCnt),“] = ”,fshow(x)); http://csg.csail.mit.edu/6.375 March 10, 2010

Writing a Testbench (Case 1) rule step0(pos==0); makeReq(17.23.12.225); pos <= 1; endrule rule step1(pos==1); getResp(); pos <= 2; rule step2(pos==2); makeReq(17.23.12.25); pos <= 3; endrule rule step3(pos==3); getResp(); pos <= 4; rule finish(pos==4); $finish; Wait until response is ready http://csg.csail.mit.edu/6.375 March 10, 2010

A more complicated Case: Initializing memory addr0 Need an FSM in HW as memory can only do one write per cycle f(i) C int i; Addr addr=addr0; bool done = False; for(i=0; i<nI; i++){ mem.write(addr++,f(i)); } done = True; Reg#(int) i <-mkReg(0); Reg#(Addr) addr <-mkReg(addr0); Reg#(Bool) done <-mkReg(False); rule initialize (i < nI); mem.write (addr, f(i)); addr <= addr + 1; i <= i + 1; if (i+1 == nI) done<=True; endrule BSV http://csg.csail.mit.edu/6.375 March 10, 2010

Initialize a memory with a 2-D pattern nJ nI i j addr0 f(i,j) Reg#(int) i <-mkReg(0); Reg#(int) j <-mkReg(0); Reg#(Addr) addr <-mkReg(addr0); Reg#(Bool) done <-mkReg(False); rule loop ((i < nI) && (j < nJ)); mem.write (addr, f(i,j)); addr <= addr + 1; if (j < nJ-1) j <= j + 1; else begin j <= 0; if (i < nI-1) i <= i + 1; else done <= True; end endrule Bluespec code gets messier as compared to C even with small changes in C, e.g., initialization based on old memory values initialization has to be done more than once http://csg.csail.mit.edu/6.375 March 10, 2010

An imperative view It is easy to write a sequence in C Writing this in rules is tedious: Can we just write the actions and have the compiler make the rules? void doTest(){ makeReq(17.23.12.225); getResp(); makeReq(17.23.12.25); exit(0); } seq makeReq(17.23.12.225); getResp(); makeReq(17.23.12.25); $finish(); endseq; http://csg.csail.mit.edu/6.375 March 10, 2010

From Action Lists to FSMs Stmt s start done FSM interface Creating an FSM interface FSM; method Action start(); method Bool done(); endinterface module mkFSM#(Stmt s)(FSM); http://csg.csail.mit.edu/6.375 March 10, 2010

The Stmt Sublanguage Stmt = <Bluespec Action> | seq s1..sN endseq | par s1..sN endpar | if-then / if-then-else | for-, while-, repeat(n)- (w/ break and continues) http://csg.csail.mit.edu/6.375 March 10, 2010

Translation Example: Seq to FSM module mkFSM_s(FSM) Reg#(Bit#(3)) pos <- mkReg(0); rule step1(pos==1); makeReq(17.23.12.225); pos <= 2; endrule rule step2(pos==2); getResp(); pos <= 3; endrule rule step3(pos==3); makeReq(17.23.12.25); pos <= 4; rule step4(pos==4); getResp(); pos <= 5; endrule rule step5(pos==5); $finish; pos <= 0; endrule method Action start() if(pos==0); pos <= 1; endmethod method Bool done() return (pos == 0); endmodule Stmt s = seq makeReq(17.23.12.225); getResp(); makeReq(17.23.12.25); $finish(); endseq; FSM f <- mkFSM(s); http://csg.csail.mit.edu/6.375 March 10, 2010

Parallel Tasks We want to check dut and ref have same result seq refReq(x); refRes(rReg); dutReq(x); dutRes(dReg); checkMatch(rReg,dReg); endseq We want to check dut and ref have same result Do each, then check results But it doesn’t matter that ref finishes before dut starts… http://csg.csail.mit.edu/6.375 March 10, 2010

Start ref and dut at the same time Seq. for each implementation Start together Both run at own rate Wait until both are done seq par seq refReq(x); refRes(refv);endseq seq dutReq(x); dutRes(dutv); endseq endpar checkMatch(refv,dutv); endseq http://csg.csail.mit.edu/6.375 March 10, 2010

What exactly is the translation? The Stmt sublanguage is clearer for the designer; but, what FSM do we get? Let’s examine each Stmt Construction case and see how it can be implemented http://csg.csail.mit.edu/6.375 March 10, 2010

Base Case: Primitive Action: a Reg#(Bool) doneR <- mkReg(True); rule dowork(!doneR); a; doneR <= True; endrule method Action start() if (doneR); doneR <= False; endmethod method Bool done(); return doneR; endmethod http://csg.csail.mit.edu/6.375 March 10, 2010

Sequential List - seq seq s1...sN endseq: sequential composition Reg#(int) s <-mkReg(0); FSM s1 <- mkFSM (s1); … ; FSM sN <- mkFSM (sN); Bool flag = rule one (s==1); s1.start(); s <= 2; endrule rule two (s==2&& s1.done()); s2.start(); s <= 3; endrule … rule n (s==n && sN-1.done()); sN.start(); s <= 0; endrule method Action start() if (flag); s <= 1; endmethod method Bool done(); return flag; endmethod s1.done() && … sN.done(); http://csg.csail.mit.edu/6.375 March 10, 2010

Implementation - par par s1...sN endpar: parallel composition FSM s1 <- mkFSM (s1); … ; FSM sN <- mkFSM (sN); Bool flag = method Action start() if (flag); s1.start(); s2.start(); …; sN.start(); endmethod method Bool done(); return flag; endmethod s1.done() && … && sN.done(); http://csg.csail.mit.edu/6.375 March 10, 2010

Implementation - if if p then sT else sF: conditional composition FSM sT <- mkFSM (sT); FSM sF <- mkFSM (sF); Bool flag = method Action start() if (flag); if (p) then sT.start() else sF.start(); endmethod method Bool done(); return flag; endmethod sT.done()&& sF.done(); http://csg.csail.mit.edu/6.375 March 10, 2010

Implementation - while while p do s: loop composition s <- mkFSM(s); Reg#(Bool) busy <- mkReg(False); Bool flag = rule restart_loop(busy && s.done()); if (p) begin s.start(); busy <= True; else busy <= False; endrule method Action start() if (flag); endmethod method Bool done(); return flag; endmethod !busy; http://csg.csail.mit.edu/6.375 March 10, 2010

The StmtFSM library This IS the Library (almost) Some optimizations for seq/base case Stmt syntax added for readability Good but not great HW (users can do better by handcoding) state-encoding Use a single wide register (i,j) instead of two Use 1 log(n)-bit register instead of n 1-bit registers See if state can be inferred from other data registers Unnecessary dead cycles can be eliminated http://csg.csail.mit.edu/6.375 March 10, 2010

FSM atomicity FSM Actions are made into rules rule atomicity governs statement interactions rule s1(…); f1.enq(x); f2.enq(x); …;endrule rule s2(…); f1.deq(); x<=x+1; … endrule rule s3(…); f2.deq(); y<=y+1; … endrule Stmt s1 = seq action f1.enq(x); f2.enq(x); endaction action f1.deq(); x<=x+1; endaction action f2.deq(); y<=y+1; endaction endseq; Stmt s2 = seq action f1.enq(y); f2.enq(y); endaction action f1.deq(); $display(“%d”, y); endaction action f2.deq(); $display(“%d”, x); endaction rule s1(…); f1.enq(y); f2.enq(y); …endrule rule s2(…); f1.deq(); $display(“%d”, y);…endrule rule s3(…); f2.deq(); y<=y+1; …endrule http://csg.csail.mit.edu/6.375 March 10, 2010

FSM Atomicity We’re writing actions, not rules Seq. Stmt par x <= x + 1; x <= 2 * x; x <= x ** 2; endpar We’re writing actions, not rules Do they execute atomically? Seq. Stmt Only one at a time  Par. Stmt all at once What happens here? http://csg.csail.mit.edu/6.375 March 10, 2010

FSM summary Stmt sublanguage captures certain common and useful FSM idioms: sequencing, parallel, conditional, iteration FSM modules automatically implement Stmt specs FSM interface permits composition of FSMs Most importantly, same Rule semantics Actions in FSMs are atomic Actions automatically block on implicit conditions Parallel actions, (in the same FSM or different FSMs) automatically arbitrated safely (based on rule atomicity) http://csg.csail.mit.edu/6.375 March 10, 2010