Computer Architecture: A Constructive Approach Bluespec execution model and concurrent rule scheduling Teacher: Yoav Etsion Taken (with permission) from.

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.
CPU Review and Programming Models CT101 – Computing Systems.
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.
2/9/20031 ECE 551: Digital System Design & Synthesis Lecture Set 4 4.1: Verilog – Procedural Assignments &Scheduling Semantics 4.2: Verilog – More Behavioral.
1 Digital Logic
Advanced Verilog EECS 270 v10/23/06.
Overview Logistics Last lecture Today HW5 due today
Maria-Cristina Marinescu Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology A Synthesis Algorithm for Modular Design of.
Maria-Cristina Marinescu Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology High-level Specification and Efficient Implementation.
Asynchronous Pipelines: Concurrency Issues Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology October 13, 2009http://csg.csail.mit.edu/koreaL12-1.
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.
Pipelining combinational circuits Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology February 20, 2013http://csg.csail.mit.edu/6.375L05-1.
Constructive Computer Architecture: Bluespec execution model and concurrency semantics 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.
Constructive Computer Architecture Cache Coherence Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology November.
Multiple Clock Domains (MCD) Continued … Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology November.
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.
ELEN 468 Lecture 131 ELEN 468 Advanced Logic Design Lecture 13 Synthesis of Combinational Logic II.
September 22, 2009http://csg.csail.mit.edu/koreaL07-1 Asynchronous Pipelines: Concurrency Issues Arvind Computer Science & Artificial Intelligence Lab.
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.
February 20, 2009http://csg.csail.mit.edu/6.375L08-1 Asynchronous Pipelines: Concurrency Issues Arvind Computer Science & Artificial Intelligence Lab Massachusetts.
Constructive Computer Architecture: Hardware Compilation of Bluespec Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of.
Operational Semantics Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Constructive Computer Architecture Store Buffers and Non-blocking Caches Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute.
Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
Computer Architecture: A Constructive Approach Multi-Cycle and 2 Stage Pipelined SMIPS Implementations Teacher: Yoav Etsion Taken (with permission) from.
Computer Architecture: A Constructive Approach Pipelining combinational circuits Teacher: Yoav Etsion Taken (with permission) from Arvind et al.*, Massachusetts.
Multiple Clock Domains (MCD) Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology.
Overview Logistics Last lecture Today HW5 due today
Introduction to Bluespec: A new methodology for designing Hardware
Introduction to Bluespec: A new methodology for designing Hardware
Concurrency properties of BSV methods and rules
Scheduling Constraints on Interface methods
CS216: Data-Intensive Computing Systems
Introduction to Bluespec: A new methodology for designing Hardware
Pipelining combinational circuits
Multirule Systems and Concurrent Execution of Rules
Constructive Computer Architecture: Guards
Pipelining combinational circuits
6.375 Tutorial 2 Guards and Scheduling Ming Liu
Constructive Computer Architecture: Well formed BSV programs
Bluespec-7: Scheduling & Rule Composition
Modeling Processors: Concurrency Issues
Modules with Guarded Interfaces
Pipelining combinational circuits
Sequential Circuits - 2 Constructive Computer Architecture Arvind
Introduction to Bluespec: A new methodology for designing Hardware
Multirule systems and Concurrent Execution of Rules
Bluespec-4: Rule Scheduling and Synthesis
Computer Science & Artificial Intelligence Lab.
Elastic Pipelines and Basics of Multi-rule Systems
Constructive Computer Architecture: Guards
GCD: A simple example to introduce Bluespec
Elastic Pipelines and Basics of Multi-rule Systems
Bluespec-7: Scheduling & Rule Composition
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
Pipelining combinational circuits
Constructive Computer Architecture: Well formed BSV programs
Presentation transcript:

Computer Architecture: A Constructive Approach Bluespec execution model and concurrent rule scheduling Teacher: Yoav Etsion Taken (with permission) from Arvind et al.*, Massachusetts Institute of Technology Derek Chiou, The University of Texas at Austin * Joel Emer, Li-Shiuan Peh, Murali Vijayaraghavan, Asif Khan, Abhinav Agarwal, Myron King 1

Content Bluespec execution model one-rule-at-a-time semantics Concurrent execution of rules a semantic view Complications due to guards Hardware intuition for concurrent execution 2 In this lecture we would take liberties with Bluespec syntax and ignore type issues

Bluespec Rule Execution A Bluespec program consists of state elements and rules, aka, Guarded Atomic Actions (GAA) that operate on the state elements Application of a rule modifies some state elements of the system in a deterministic manner Let s’ = a(s) where s’ represents the state obtained by applying action a to state s We can define the application of a rule by either giving a procedure or by describing a hardware circuit to compute the new state current state next state values next state computation f x f x guard reg en’s nextState AND 3

Bluespec Execution Model Repeatedly: Select a rule to execute Compute the state updates Make the state updates All legal behaviors of a Bluespec program can be generated by applying one rule at a time (may be more than one legal behavior) Given a program prog with a set of rules rule r1 a1; rule r2 a2; … and initial state s0, state s is legal for prog if and only iff there exist a sequence of rules ri, rj, rk,… such that s = …ak(aj(ai(s0)))… 4

Legal Bluespec rules A legal Bluespec rule does not contain multiple non-blocking assignments to the same state element or combinational cycles Examples: legal? rule ra if(z>10); x <= x+1; endrule rule rb; x <= x+1; if p then x <= 7 endrule rule rc; x <= y+1; y <= x+2 endrule rule rd; t1 = f(t2); t2 = g(t1); x <= t1; endrule no yes no In general the legality of a rule can be determined only at run time. 5

Concurrent scheduling of rules The one-rule-at-a-time semantics plays the central role in defining functional correctness and verification However, for meaningful hardware design it is necessary to execute multiple rules concurrently without violating the one-rule- at-a-time semantics What do we mean by concurrent scheduling? a semantic view some hardware intuition 6

Concurrent scheduling: Semantic view Suppose rule r1 a1 and rule r2 a2 are legal rules. r1 and r2 are concurrently schedulable, iff, 1. rule r12 (a1;a2) is legal 2. for all s, (a1;a2)(s) = a1(a2(s)) or a2(a1(s)) Concurrent scheduling of two rules, when permitted, can be expressed as a new derived rule, i.e., r12 The above characterization of rule r12 is not totally correct in the presence of guards; we will fix is shortly 7

Example 1 {x0,y0,30}  ra {x0+1,y0,30}  rb {x0+1,y0+2,30} {x0,y0,30}  rb {x0,y0+2,30}  ra {x0+1,y0+2,30} {x0,y0,30}  ra_rb {x0+1,y0+2,30} {x0,y0,15}  ra {x0+1,y0,15}  rb {x0+1,y0,15} {x0,y0,15}  rb {x0,y0,15}  ra {x0+1,y0,15} {x0,y0,15}  ra_rb {x0+1,y0,15} Parallel execution behaves like ra < rb (i.e., rb(ra(s)) = rb < ra (i.e., ra(rb(s)) rule ra if (z>10); x <= x+1; endrule rule rb if (z>20); y <= y+2; endrule rule ra_rb; if (z>10) x <= x+1; if (z>20) y <= y+2; endrule 8

Example 2 {x0,y0,30}  ra {y0+1,y0,30}  rb {y0+1,y0+1+2,30} {x0,y0,30}  rb {x0,x0+2,30}  ra {x0+2+1,x0+2,30} {x0,y0,30}  ra_rb {y0+1,x0+2,30} rule ra if (z>10); x <= y+1; endrule rule rb if (z>20); y <= x+2; endrule rule ra_rb; if (z>10) x <= y+1; if (z>20) y <= x+2; endrule Rule ra_rb is legal but does not behave like either ra < rb or rb < ra Rules ra and rb conflict and can’t be scheduled concurrently 9

Example 3 {x0,y0,30}  ra {y0+1,y0,30}  rb {y0+1,y0+2,30} {x0,y0,30}  rb {x0,y0+2,30}  ra {y0+2+1,y0+2,30} {x0,y0,30}  ra_rb {y0+1,y0+2,30} rule ra if (z>10); x <= y+1; endrule rule rb if (z>20); y <= y+2; endrule rule ra_rb; if (z>10) x <= y+1; if (z>20) y <= y+2; endrule Rule ra_rb is legal and behaves like ra < rb (i.e., rb(ra(s))) Rules ra and rb can be scheduled concurrently with the functionality ra < rb 10

Example 4 rule ra; x <= y+1; u <= u+2; endrule rule rb; y <= y+2; v <= u+1; endrule rule ra_rb; x <= y+1; u <=u+2; y <= y+2; v <=u+1; endrule Rule ra_rb is legal but does not behave like either ra < rb or rb < ra Notice read/write accesses to y can be resolved by ordering ra < rb while accesses to u can be resolved by ordering rb < ra. Since these orderings are contradictory these rules conflict and cannot be scheduled concurrently 11

Complication due to guards 12

Making guards explicit rule foo if (True); if (p) fifo.enq(8); r <= 7; endrule rule foo if ((p && fifo.notFull) || !p); if (p) fifo.enq(8); r <= 7; endrule Effectively, all implicit conditions (guards) are lifted and conjoined to the rule guard 13

Implicit guards (conditions) rule if ( ); ; endrule make implicit guards explicit m.g B ( ) when m.g G ::= r | if ( ) | ; | m.g( ) | t = ::= r | if ( ) | when ( ) | ; | m.g( ) | t = 14

Guards vs If’s A guard on one action of a parallel group of actions affects every action within the group (a1 when p1); a2 [ think: f.deq; a2 ] ==> (a1; a2) when p1 A condition of a Conditional action only affects the actions within the scope of the conditional action (if (p1) a1); a2 p1 has no effect on a2... Mixing ifs and whens (if (p) (a1 when q)) ; a2[ if(p) f.deq; a2 ]  ((if (p) a1); a2) when ((p && q) | !p)  ((if (p) a1); a2) when (q | !p) 15

Guard Lifting rules All the guards can be “lifted” to the top of a rule (a1 when p) ; a2  (a1 ; a2) when p a1 ; (a2 when p)  (a1 ; a2) when p if (p when q) then a  (if p then a) when q if p then (a when q)  (if p then a) when (q | !p) (a when p1) when p2  a when (p1 & p2) x <= (e when p)  (x <= e) when p similarly for expressions... Rule r p1 (a when p)  Rule r (if (p and p1) a) Bluespec provides a primitive (impCondOf) to make guards explicit and lift them to the top 16

Concurrent scheduling test: corrected Suppose rule r1 a1 and rule r2 a2 are legal rules. r1 and r2 are concurrently schedulable, iff, 1. rule r12 (a1’ ; a2’) is legal where a1’ = if (impCondOf(a1)) a1 a2’ = if (impCondOf(a2)) a2 2. s, (a1’;a2’)(s) = a1’(a2’(s)) or a2’(a1’(s)) Concurrent scheduling of two rules, when permitted, can be expressed as the new derived rule r12 17

Making life easier Removing guards a when q => If (impCondOf(a) a) If (p) a when q => If (p && impCondOf(a) a) Implicit condition is removed Need to set bsc option -aggressive-conditions -aggressive-conditions 18

Hardware intuition for concurrent scheduling 19

some insight into Concurrent rule firing There are more intermediate states in the rule semantics (a state after each rule step) In the HW, states change only at clock edges Rules HW RiRjRk clocks rule steps Ri Rj Rk 20

Parallel execution reorders reads and writes In the rule semantics, each rule sees (reads) the effects (writes) of previous rules In the HW, rules only see the effects from previous clocks, and only affect subsequent clocks Rules HW clocks rule steps readswritesreadswritesreadswritesreadswritesreadswrites readswritesreadswrites 21

Correctness Rules are allowed to fire in parallel only if the net state change is equivalent to sequential rule execution Consequence: the HW can never reach a state unexpected in the rule semantics Rules HW RiRjRk clocks rule steps Ri Rj Rk 22

Compiling a Rule f x current state next state   guard f x rule r (f.first() > 0) ; x <= x + 1 ; f.deq (); endrule rdy signals read methods next state values 23

Combining State Updates: strawman next state value latch enable R OR 11 nn  1,R  n,R OR ’s from the rules that update R ’s from the rules that update R What if more than one rule is enabled? 24

Combining State Updates next state value latch enable R Scheduler: Priority Encoder OR 11 nn 11 nn  1,R  n,R OR ’s from the rules that update R Scheduler ensures that at most one  i is true ’s from all the rules one-rule-at- a-time scheduler is conservative 25

A compiler test for concurrent rule firing James Hoe, Ph.D., 2000 Let R(r) represent the set of registers a rule r may read Let W(r) represent the set of registers a rule r may write Rules ra and rb are conflict free (CF) if R(ra)W(rb) =   R(rb)W(ra) =   W(ra)W(rb) =  Rules ra and rb are sequentially composable (ra<rb) if R(rb)W(ra) =   W(ra)W(rb) =  26

Scheduling and control logic Modules (Current state) Rules   Scheduler 11 nn 11 nn Muxing 11 nn nn nn Modules (Next state) cond action “CAN_FIRE”“WILL_FIRE” Compiler synthesizes a scheduler such that at any given time ’s for only non-conflicting rules are true 27

What Did We Learn? The rules of firing Bluespec rules One-rule-at-a-time When rules can fire concurrently Interaction between guards and conditional actions Compiler analysis to determine the conflict free property Compiler generated hardware scheduler Hardware intuition and implementation 28