Concurrency properties of BSV methods and rules

Slides:



Advertisements
Similar presentations
BSV execution model and concurrent rule scheduling Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology February.
Advertisements

Elastic Pipelines and Basics of Multi-rule Systems Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology February.
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.
EHRs: Designing modules with concurrent methods Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology February 27,
Computer Architecture: A Constructive Approach EHRs: Designing modules with concurrent methods Teacher: Yoav Etsion Taken (with permission) from Arvind.
Asynchronous Pipelines: Concurrency Issues Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology October 13, 2009http://csg.csail.mit.edu/koreaL12-1.
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.
December 10, 2009 L29-1 The Semantics of Bluespec Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute.
December 12, 2006http://csg.csail.mit.edu/6.827/L24-1 Scheduling Primitives for Bluespec Arvind Computer Science & Artificial Intelligence Lab Massachusetts.
Pipelining combinational circuits Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology February 20, 2013http://csg.csail.mit.edu/6.375L05-1.
Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
Constructive Computer Architecture: Guards Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology September 24, 2014.
Constructive Computer Architecture Tutorial 2 Advanced BSV Andy Wright TA September 26, 2014http://csg.csail.mit.edu/6.175T02-1.
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.
Constructive Computer Architecture: Control Hazards Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology October.
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,
Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
Computer Architecture: A Constructive Approach Bluespec execution model and concurrent rule scheduling Teacher: Yoav Etsion Taken (with permission) from.
October 20, 2009L14-1http://csg.csail.mit.edu/korea Concurrency and Modularity Issues in Processor pipelines Arvind Computer Science & Artificial Intelligence.
Elastic Pipelines: Concurrency Issues
EHRs: Designing modules with concurrent methods
EHRs: Designing modules with concurrent methods
Bluespec-6: Modeling Processors
Scheduling Constraints on Interface methods
Sequential Circuits - 2 Constructive Computer Architecture Arvind
Sequential Circuits Constructive Computer Architecture Arvind
Sequential Circuits: Constructive Computer Architecture
Performance Specifications
Pipelining combinational circuits
Multirule Systems and Concurrent Execution of Rules
Constructive Computer Architecture: Guards
Sequential Circuits Constructive Computer Architecture Arvind
Pipelining combinational circuits
EHR: Ephemeral History Register
Constructive Computer Architecture: Well formed BSV programs
Bluespec-7: Scheduling & Rule Composition
Control Hazards Constructive Computer Architecture: Arvind
Modeling Processors: Concurrency Issues
Modules with Guarded Interfaces
Pipelining combinational circuits
Sequential Circuits - 2 Constructive Computer Architecture Arvind
Elastic Pipelines: Concurrency Issues
Multirule systems and Concurrent Execution of Rules
Stmt FSM Arvind (with the help of Nirav Dave)
Computer Science & Artificial Intelligence Lab.
Elastic Pipelines: Concurrency Issues
Pipelined Processors Arvind
Elastic Pipelines and Basics of Multi-rule Systems
Constructive Computer Architecture: Guards
Elastic Pipelines and Basics of Multi-rule Systems
Bluespec-7: Scheduling & Rule Composition
Control Hazards Constructive Computer Architecture: Arvind
Pipelined Processors Constructive Computer Architecture: Arvind
Multirule systems and Concurrent Execution of Rules
Introduction to Bluespec: A new methodology for designing Hardware
Bluespec-7: Semantics of Bluespec
Bluespec-5: Scheduling & Rule Composition
Modular Refinement Arvind
Control Hazards Constructive Computer Architecture: Arvind
Implementing for Correct Concurrency
Constructive Computer Architecture: Well formed BSV programs
Caches-2 Constructive Computer Architecture Arvind
Presentation transcript:

Concurrency properties of BSV methods and rules Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology February 22, 2016 http://csg.csail.mit.edu/6.375

One-rule-at-a-time semantics Given a program with a set of rules {rule ri ai} and an initial state S0 , S is a legal state if and only if there exists a sequence of rules rj1,…., rjn such that S= ajn(…(aj1(S0))…) February 22, 2016 http://csg.csail.mit.edu/6.375

Concurrent execution of two rules Concurrent execution of two rules, rule r1 a1 and rule r2 a2, means executing a rule whose body looks like (a1; a2), that is a rule which is a parallel composition of the actions of the two rules with the following restrictions to preserve the one-rule-at-a-time semantics: Either S. (a1; a2)(S) = a2(a1(S)) or S. (a1; a2)(S) = a1(a2(S)) February 22, 2016 http://csg.csail.mit.edu/6.375

Concurrent scheduling of rules rule r1 a1 to rule rn an can be scheduled concurrently, preserving one-rule-at-a-time semantics, if and only if there exists a permutation (p1,…,pn) of (1,…,n) such that S. (a1;…;an)(S) = apn(…(ap1(S)) How does a compiler decide which rules can be scheduled concurrently Related question: what is a legal rule? February 22, 2016 http://csg.csail.mit.edu/6.375

Well formed actions (rules) informally No possibility of double write error. In general, no double use of a method The only exception is a value method without arguments, e.g., register read, fifo.first No combinational cycles. In general it means that it should be possible to put all the method calls in a sequential order consistent with their module definitions and data dependences February 22, 2016 http://csg.csail.mit.edu/6.375

Are these actions legal? x <= e1; x <= e2; x <= e1; if( p ) x <= e2; if( p ) x <= e1; else x <= e2; x[0] <= x[1] x[0] <= y[1]; y[0] <= x[1] if (x[1]) x[0] <= e; No - Double write No - Double write Yes – Mutually Exclusive No X x[0] x[1] 1 EHR Combinational cycle No No February 22, 2016 http://csg.csail.mit.edu/6.375

A critical example Example 1: Rule exchange x <= y; y <= x Example 2: Rule exchange’ f() ; g() where Module foo register x, y etc method f() = (x <= y); method g() = (y <= x); Example 3: Rule fr; x <= y; Rule gr; y <= x; Is exchange legal? Yes Is exchange’ legal? Do f and g conflict? Tricky! Can rules fr and gr be executed together? No February 22, 2016 http://csg.csail.mit.edu/6.375

Primitive module: Register read and write can happen in the same atomic action and don’t affect each other; the effect of write is not visible until the atomic action has completed Legality of an action depends upon the permitted intra-rule behaviors Concurrent scheduling depends upon the inter-rule behavior reg.r reg.w CF C Intra-rule behavior reg.r reg.w CF < > C Inter-rule behavior February 22, 2016 http://csg.csail.mit.edu/6.375

Primitive module: EHR Intra-rule behavior Inter-rule behavior EHR.r0 EHR.w0 EHR.r1 EHR.w1 CF C CF CF CF Intra-rule behavior CF < < CF > CF CF > CF EHR.r0 EHR.w0 EHR.r1 EHR.w1 CF < > C Inter-rule behavior February 22, 2016 http://csg.csail.mit.edu/6.375

Intra-rule analysis “Happens before” (<) relation “happens before” relation between the methods of a module governs how the methods behave when called by a rule, action, method or exp f < g : f happens before g (g cannot affect f within an action) f > g : g happens before f C : f and g conflict and cannot be called together CF : f and g are conflict free and do not affect each other This relation is defined as a conflict matrix (CM) for the methods of primitive modules like registers and EHRs and derived for the methods of all other modules February 22, 2016 http://csg.csail.mit.edu/6.375

Inter-rule analysis “Happens before” (<) relation “happens before” relation between the methods of a module governs how the methods behave when called by two rules or methods f < g : parallel: but g may affect f in a seq execution f > g : parallel: but f may affect g in a seq execution C : not parallel: f and g conflict CF : parallel: f and g are conflict free and unrelated This relation is defined as a conflict matrix (CM) for the methods of primitive modules like registers and EHRs and derived for the methods of all other modules February 22, 2016 http://csg.csail.mit.edu/6.375

Conflict ordering CF = {<,>} {<} {>} C = {} This permits us to take intersections of conflict information, e.g., {>}{<,>} = {>} {>}{<} = {} February 22, 2016 http://csg.csail.mit.edu/6.375

Some definitions mcalls(x) is the set of method called by x mcalls(x) <s mcalls(y) means a  mcalls(x), b  mcalls(y) => (a < b) | (a CF b) | (a ME b) we often overload < and use it in place of <s To be explained later February 22, 2016 http://csg.csail.mit.edu/6.375

Deriving the Conflict Matrix (CM) of a module Let g1 and g2 be the two methods defined by a module, such that mcalls(g1)={g11,g12...g1n} mcalls(g2)={g21,g22...g2m} conflict(x,y) = if x and y are methods of the same module then CM[x,y] else CF Derivation CM[g1,g2] = conflict(g11,g21)  conflict(g11,g22) ...  conflict(g12,g21)  conflict(g12,g22) ... …  conflict(g1n,g21)  conflict(g12,g22) ... Compiler can derive the CM for a module by starting with the innermost modules in the module instantiation tree February 22, 2016 http://csg.csail.mit.edu/6.375

Data-dependence constraints if (e) a  NewDependences(mcalls(e), mcalls(a)) m.g(e)  NewDependences(mcalls(e), {m.g}) t = e ; a  NewDependences(mcalls(e) , {f | f  mcalls(a) & f uses t}) An action is legal if the data-dependence imposed constraints together with method definition constraints can be placed in a total order (no cycles) February 22, 2016 http://csg.csail.mit.edu/6.375

Real legal-rule analysis is more complicated: Predicated calls The analysis we presented would reject the following rule because of method conflicts if (p) m.g(e1) ; if (!p) m.g(e2) We need to keep track of the predicates associated with each method call m.g is called with predicates p and !p which are disjoint – therefore no conflict February 22, 2016 http://csg.csail.mit.edu/6.375

Mutually exclusive actions a1 and a2 are mutually exclusive if in all possible states the effect of one of them is “no action” example: a1 = if (p) b1 a2 = if (!p) b2 Mutual exclusivity of actions and methods reduces the number of conflicts at the cost of complicating the analysis In computing the conflict matrix (CM) one can ignore entries corresponding to mutually exclusive methods In determining the legality of an action (rule) one can ignore the ordering constraints between mutually exclusive sub-actions February 22, 2016 http://csg.csail.mit.edu/6.375

Some examples to intra-rule and inter-rule analysis February 22, 2016 http://csg.csail.mit.edu/6.375

CM for One-Element FIFO module mkPipelineFifo(Fifo#(1, t)) provisos(Bits#(t, tSz)); Reg#(t) d <- mkRegU; Reg#(Bool) v <- mkReg(False); method Action enq(t x) if (!v); d <= x; v <= True; endmethod method Action deq if (v); v <= False; method t first if (v); return d; endmodule mcalls(enq) = mcalls(deq) = mcalls(first) = {v.r, d.w, v.w} {v.r, v.w} {v.r, d.r} Notice enq and deq are mutually exclusive February 22, 2016 http://csg.csail.mit.edu/6.375

CM for One-Element FIFO mcalls(enq) = {v.r, d.w, v.w} mcalls(deq) = {v.r, v.w} mcalls(first) = {v.r, d.r} enq deq first C ME CF Intra-rule CM enq deq first C ME > < CF Inter-rule CM February 22, 2016 http://csg.csail.mit.edu/6.375

CM for One-Element Pipeline FIFO module mkPipelineFifo(Fifo#(1, t)) provisos(Bits#(t, tSz)); Reg#(t) d <- mkRegU; Ehr#(2, Bool) v <- mkEhr(False); method Action enq(t x) if (!v[1]); d <= x; v[1] <= True; endmethod method Action deq if (v[0]); v[0] <= False; method t first if (v[0]); return d; endmodule mcalls(enq) = mcalls(deq) = mcalls(first) = {v.r1, d.w, v.w1} {v.r0, v.w0} {v.r0, d.r} February 22, 2016 http://csg.csail.mit.edu/6.375

CM for One-Element Pipeline FIFO mcalls(enq) = {v.r1, d.w, v.w1} mcalls(deq) = {v.r0, v.w0} mcalls(first) = {v.r0, d.r} CM[enq,deq] = conflict[v.r1,v.r0]  conflict[v.r1,v.w0]  conflict[d.w,v.r0]  conflict[d.w,v.w0]  conflict[v.w1,v.r0]  conflict[v.w1,v.w0] Intra-rule derivation = CF  {>}  CF  CF  {>}  {>} = {>} enq deq first C > < CF enq deq first C > < CF Intra-rule Inter-rule February 22, 2016 http://csg.csail.mit.edu/6.375

CM for One-Element Bypass FIFO module mkBypassFifo(Fifo#(1, t)) provisos(Bits#(t, tSz)); Ehr#(2, t) d <- mkEhr(?); Ehr#(2, Bool) v <- mkEhr(False); method Action enq(t x) if !v[0]; d[0] <= x; v[0] <= True; endmethod method Action deq if v[1]; v[1] <= False; ` method t first if v[1]; return d[1]; endmodule mcalls(enq) = mcalls(deq) = mcalls(first) = {v.r0, d.w0, v.w0} {v.r1, v.w1} {v.r1, d.r1} February 22, 2016 http://csg.csail.mit.edu/6.375

CM for One-Element Bypass FIFO mcalls(enq) = {d.w0, v.w0, v.r0} mcalls(deq) = {v.r1, v.w1} mcalls(first) = {v.r1, d.r1} CM[enq,deq] = conflict[d.w0,v.r1]  conflict[d.w0,v.w1]  conflict[v.w0,v.r1]  conflict[v.w0,v.w1]  conflict[v.r0,v.r1]  conflict[v.r0,v.w1] Intra-rule derivation = {<} Enq Deq First C < > CF Enq Deq First C < > CF Intra-rule Inter-rule February 22, 2016 http://csg.csail.mit.edu/6.375

CM for Two-Element Conflict-free FIFO db da module mkCFFifo(Fifo#(2, t)) provisos(Bits#(t, tSz)); Ehr#(2, t) da <- mkEhr(?); Ehr#(2, Bool) va <- mkEhr(False); Ehr#(2, t) db <- mkEhr(?); Ehr#(2, Bool) vb <- mkEhr(False); rule canonicalize(vb[1] && !va[1]); da[1] <= db[1]; va[1] <= True; vb[1] <= False; endrule method Action enq(t x) if va[0]; db[0] <= x; vb[0] <= True; endmethod method Action deq if !vb[0]; va[0] <= False endmethod method t first if !vb[0]; return da[0]; endmethod endmodule Derive the CM February 22, 2016 http://csg.csail.mit.edu/6.375

Extending CM to rules using inter-rule CMs CM between two rules is computed exactly the same way as CM for the methods of a module Given rule r1 a1 and rule r2 a2 such that mcalls(a1)={g11,g12...g1n} mcalls(a2)={g21,g22...g2m} Compute Conflict(x,y) = if x and y are methods of the same module then CM[x,y] else CF CM[r1,r2] = conflict(g11,g21)  conflict(g11,g22) ...  conflict(g12,g21)  conflict(g12,g22) ... …  conflict(g1n,g21)  conflict(g12,g22) ... Conflict relation is not transitive r1 < r2, r2 < r3 does not imply r1 < r3 February 22, 2016 http://csg.csail.mit.edu/6.375

Using CMs for concurrent scheduling of rules Two rules that are conflict free can be scheduled together without violating the one-rule-at-a-time semantics. In general, use the following theorem Theorem: Given a set of rules {rule ri ai}, if there exists a permutation {p1, p2 … pn} of {1..n} such that  i < j. CM(api, apj) is CF or < or ME then the rules r1, r2 … rn can be scheduled concurrently with the effect  i, j. rpi < rpj A compiler can perform the analysis needed for concurrent scheduling of rules James Hoe, 2000 February 22, 2016 http://csg.csail.mit.edu/6.375

Scheduling constraints due to multiple modules rb aTob bToa x y Can ra and rb be scheduled concurrently? rule ra; aTob.enq(fa(x)); x <= ga(bToa.first); bToa.deq; endrule rule rb; y <= gb(aTob.first); aTob.deq; bToa.enq(fb(y)); Endrule // assume both fifos are not empty fifos are initially empty aTob bToa Concurrent fifo fifo scheduling? CF CF CF pipeline CF bypass pipeline CF pipeline pipeline pipeline bypass bypass CF bypass pipeline bypass bypass     x    x February 17, 2016 http://csg.csail.mit.edu/6.375

Extras February 22, 2016 http://csg.csail.mit.edu/6.375

CM for Two-Element Conflict-free FIFO mcalls(enq) = { } mcalls(deq) = { } mcalls(first) = { } Fill the CM CM[enq,deq] = Enq Deq First Canon C CF February 22, 2016 http://csg.csail.mit.edu/6.375

Example 1: Compiler Analysis rule ra; if (z>10) x <= x+1; endrule rule rb; if (z>20) y <= y+2; mcalls(ra) = {z.r, x.w, x.r} mcalls(rb) = {z.r, y.w, y.r} CM(ra, rb) = conflict(z.r, z.r)  conflict(z.r, y.w) conflict(z.r, y.r)  conflict(x.w, z.r) conflict(x.w, y.w)  conflict(x.w, y.r) conflict(x.r, z.r)  conflict(x.r, y.w) Conflict(x.r, y.r) = CF  CF  CF  CF … = CF Rules ra and rb can be scheduled together without violating the one-rule-at-a-time-semantics. We say rules ra and rb are CF February 22, 2016 http://csg.csail.mit.edu/6.375

Example 2: Compiler Analysis mcalls(ra) = {z.r, x.w, y.r} mcalls(rb) = {z.r, y.w, x.r} CM(ra, rb) = conflict(z.r, z.r)  conflict(z.r, y.w) conflict(z.r, x.r)  conflict(x.w, z.r) conflict(x.w, y.w)  conflict(x.w, x.r) conflict(y.r, z.r)  conflict(y.r, y.w) Conflict(y.r, x.r) = CF  CF CF  CF CF  > CF  <  CF = C rule ra; if (z>10) x <= y+1; endrule rule rb; if (z>20) y <= x+2; Rules ra and rb cannot be scheduled together without violating the one-rule-at-a-time-semantics. Rules ra and rb are C February 22, 2016 http://csg.csail.mit.edu/6.375

Example 3: Compiler Analysis mcalls(ra) = {z.r, x.w, y.r} mcalls(rb) = {z.r, y.w, y.r} CM(ra, rb) = conflict(z.r, z.r)  conflict(z.r, y.w) conflict(z.r, y.r)  conflict(x.w, z.r) conflict(x.w, y.w)  conflict(x.w, y.r) conflict(y.r, z.r)  conflict(y.r, y.w) Conflict(y.r, y.r) = CF  CF CF  CF CF  <  CF = < rule ra; if (z>10) x <= y+1; endrule rule rb; if (z>20) y <= y+2; Rules ra and rb can be scheduled together without violating the one-rule-at-a-time-semantics. Rule ra < rb February 22, 2016 http://csg.csail.mit.edu/6.375

Data Dependence - Conflict Matrix reg.r reg.w ND,CF ND,< ND,> DW,C Register EHR.r0 EHR.w0 EHR.r1 EHR.w1 ND,CF ND,< ND,> DW,C L,< R,> EHR February 22, 2016 http://csg.csail.mit.edu/6.375

Conflict Matrix of Primitive modules: Registers and EHRs reg.r reg.w CF <a >a C Register EHR.r0 EHR.w0 EHR.r1 EHR.w1 CF <a CF? < >a C > EHR February 22, 2016 http://csg.csail.mit.edu/6.375

New Conflict ordering CF = {<,>} {<a} {>a} {<} {>} C = {} This permits us to take intersections of conflict information, e.g., {>}{<,>} = {>} {>}{<} = {} February 22, 2016 http://csg.csail.mit.edu/6.375