Stmt FSM Richard S. Uhler Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology (based on a lecture prepared by Arvind)

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.
Constructive Computer Architecture: Multirule systems and Concurrent Execution of Rules Arvind Computer Science & Artificial Intelligence Lab. Massachusetts.
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.
Asynchronous Pipelines: Concurrency Issues Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology October 13, 2009http://csg.csail.mit.edu/koreaL12-1.
Modeling Processors Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology February 22, 2011L07-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.
Constructive Computer Architecture Sequential Circuits Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology September.
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.
February 20, 2009http://csg.csail.mit.edu/6.375L08-1 Asynchronous Pipelines: Concurrency Issues Arvind Computer Science & Artificial Intelligence Lab Massachusetts.
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
Introduction to Computing Systems and Programming Programming.
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.
Modeling Processors Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology March 1, 2010
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
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
Stmt FSM Arvind (with the help of Nirav Dave)
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
Implementing for Correct Concurrency
Caches-2 Constructive Computer Architecture Arvind
Presentation transcript:

Stmt FSM Richard S. Uhler Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology (based on a lecture prepared by Arvind) March 7, 2011 L10-1http://csg.csail.mit.edu/6.375

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) March 7, 2011 L10-2http://csg.csail.mit.edu/6.375

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

Testing IP Lookup Call many streams of requests responses from the device under test (DUT) Case 1 dut.enter( ) dut.getResult() dut.enter( ) dut.getResult() Case 2 dut.enter( ) dut.enter( ) dut.getResult() Check correct with 1 request at a time Check correct with 2 concurrent requests March 7, 2011 L10-4http://csg.csail.mit.edu/6.375

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(); action resCnt <= resCnt + 1; let x <- dut.getResult(); $display(“[Rsp #:”,fshow(resCnt),“] = ”,fshow(x)); endaction endfunction March 7, 2011 L10-5http://csg.csail.mit.edu/6.375

Writing a Testbench (Case 1) rule step0(pos==0); makeReq( ); pos <= 1; endrule rule step1(pos==1); getResp(); pos <= 2; endrule rule step2(pos==2); makeReq( ); pos <= 3; endrule rule step3(pos==3); getResp(); pos <= 4; endrule rule finish(pos==4); $finish; endrule A lot of text! Wait until response is ready How should we do it for a sequence of 100 actions? March 7, 2011 L10-6http://csg.csail.mit.edu/6.375

A more complicated Case: Initializing memory f(i) nIiaddr0 int i; Addr addr=addr0; bool done = False; for(i=0; i<nI; i++){ mem.write(addr++,f(i)); } done = True; C Need an FSM in HW as memory can only do one write per cycle 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 March 7, 2011 L10-7http://csg.csail.mit.edu/6.375

Initialize a memory with a 2-D pattern 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 f(i,j) nJ nI i jaddr0 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 Shall we do triply-nested loops? March 7, 2011 L10-8http://csg.csail.mit.edu/6.375

An imperative view void doTest(){ makeReq( ); getResp(); makeReq( ); getResp(); exit(0); } seq makeReq( ); getResp(); makeReq( ); getResp(); $finish(); endseq; 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? March 7, 2011 L10-9http://csg.csail.mit.edu/6.375

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

The Stmt Sublanguage Stmt = | seq s1..sN endseq | par s1..sN endpar | if-then / if-then-else | for-, while-, repeat(n)- (w/ break and continues) BSV Action Sequence of Stmt List of Parallel Stmts Conditional Stmts Loop Stmts March 7, 2011 L10-11http://csg.csail.mit.edu/6.375

Translation Example: Seq to FSM Stmt s = seq makeReq( ); getResp(); makeReq( ); getResp(); $finish(); endseq; FSM f <- mkFSM(s); module mkFSM_s(FSM) Reg#(Bit#(3)) pos <- mkReg(0); rule step1(pos==1); makeReq( ); pos <= 2; endrule rule step2(pos==2); getResp(); pos <= 3; endrule rule step3(pos==3); makeReq( ); pos <= 4; endrule 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); endmethod endmodule March 7, 2011 L10-12http://csg.csail.mit.edu/6.375

Parallel Tasks 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… March 7, 2011 L10-13http://csg.csail.mit.edu/6.375

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 seqrefReq(x); refRes(refv);endseq seqdutReq(x); dutRes(dutv); endseq endpar checkMatch(refv,dutv); endseq March 7, 2011 L10-14http://csg.csail.mit.edu/6.375

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 March 7, 2011 L10-15http://csg.csail.mit.edu/6.375

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 March 7, 2011 L10-16http://csg.csail.mit.edu/6.375

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 What is wrong if we just had this? s1.done() && … sN.done(); March 7, 2011 L10-17http://csg.csail.mit.edu/6.375

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(); March 7, 2011 L10-18http://csg.csail.mit.edu/6.375

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(); March 7, 2011 L10-19http://csg.csail.mit.edu/6.375

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); if (p) begin s.start(); busy <= True; else busy <= False; endmethod method Bool done(); return flag; endmethod !busy; what if this was replaced by busy <= True March 7, 2011 L10-20http://csg.csail.mit.edu/6.375

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 March 7, 2011 L10-21http://csg.csail.mit.edu/6.375

FSM atomicity FSM Actions are made into rules rule atomicity governs statement interactions 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 endseq; 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 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 March 7, 2011 L10-22http://csg.csail.mit.edu/6.375

FSM Atomicity We’re writing actions, not rules Do they execute atomically? Seq. Stmt Only one at a time  Safe Par. Stmt all at once  What about conflicts? par x <= x + 1; x <= 2 * x; x <= x ** 2; endpar What happens here?  rule p1; x <= x + 1;…endrule  rule p2; x <= 2 * x;…endrule  rule p3; x <=x ** 2;…endrule Each rule happens once. Order is arbitrary March 7, 2011 L10-23http://csg.csail.mit.edu/6.375

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) March 7, 2011 L10-24http://csg.csail.mit.edu/6.375