Bluespec. Lectures 3 & 4 with some slides from Nikhil Rishiyur at Bluespec and Simon Moore at the University of Cambridge

Transcription

1 Bluespec Lectures 3 & 4 with some slides from Nikhil Rishiyur at Bluespec and Simon Moore at the University of Cambridge

2 Course Resources Lecture notes (Power Point, PDF) Example Bluespec programs used in Lectures Complete Photoshop system (Bluespec) Links to Bluespec code samples User guide, reference guide: doc subdirectory of Bluespec installation More information at

3 Rules, not clock edges rules are atomic they execute within one clock cycle structure: rule name (explicit conditions) statements; conditions: explicit conditions (Boolean expression) provided implicit conditions that have to be met to allow the statements to fire, e.g. for fifo.enq only if fifo not full

4 Rules: powerful alternative to always blocks rules for state updates instead of always blocks Simple concept: think if then rule rulename (<boolean cond>); <state update(s)> Rule can execute (or fire ) only when its conditions are TRUE Every rule is atomic with respect to other rules Powerful ramifications: Executable specification design around operations as described in specs Atomicity of rules dramatically reduces concurrency bugs Automates management of shared resources avoids many complex errors

5 Bits, Bools and conversion Bit#(width) vector of bits Bool single bit for Booleans (True, False) pack() function to convert most things (pack) into a bit representation unpack() opposite of pack() extend() extend an integer (signed, unsigned, bits) truncate() truncate an integer

6 Reg and Bit/Uint/Int types registers (initialised and uninitialised versions): Reg#(type) name0 <- mkreg(initial_value); Reg#(type) name1 <- mkregu; interface type type parameter (e.g. UInt#(8)) since Reg is generic name of module to make (i.e. instantiate) N.B. modules are typically prefixed mk some types (unsigned and signed integer, and bits): UInt#(width), Int#(width), Bit#(width) example: Reg#(UInt#(8)) counter <- mkreg(0); rule count_up; counter <= counter+1;

7 Registers interface Reg#(type a); method Action _write (a x1); method a _read (); endinterface: Reg Polymorphic Just library elements In one cycle register reads must execute before register writes x <= y + 1 is syntactic sugar for x._write (y._read + 1)

8 Scheduling Annotations C CF SB SBR SA SAR Conflict Conflict free Sequence before Sequence before restricted (cannot be in the same rule) Sequence after Sequence after restricted (cannot be in the same rule)

9 Scheduling Annotations for a Register read write read CF SB write SA SBR Two read methods would be conflict-free (CF), that is, you could have multiple methods that read from the same register in the same rule, sequenced in any order. A write is sequenced after (SA) a read. A read is sequenced before (SB) a write. If you have two write methods, one must be sequenced before the other, and they cannot be in the same rule, as indicated by the annotation SBR.

10 Updating Registers Reg#(int) x <- mkreg (0) ; rule countup (x < 30); int y = x + 1; x <= x + 1; $display ("x = %0d, y = %0d", x, y);

11 Rules of Rules (The Three Basics) 1. Rules are atomic 2. Rules fire or don t at most once per cycle 3. Rules don t conflict with other rules

12 D x Q +1 D y Q +1 rule r1; x <= y + 1; rule r2; y <= x + 1; clk

13 (* synthesize *) module rules4 (Empty); D x2 Q +1 Reg#(int) x <- mkreg (10); Reg#(int) y <- mkreg (100); rule r1; x <= y + 1; D y2 Q +1 rule r2; y <= x + 1; clk $./rules4 -m 5 x, y = 10, 100 x, y = 10, 11 x, y = 10, 11 x, y = 10, 11 rule monitor; $display ("x, y = %0d, %0d ", x, y); endmodule

14 D x Q +1 (* synthesize *) module rules5 (Empty); Reg#(int) x <- mkreg (10); Reg#(int) y <- mkreg (100); D y Q +1 rule r ; x <= y + 1; y <= x + 1; clk rule monitor; $display ("x, y = %0d, %0d ", x, y); endmodule $./rules5 -m 5 x, y = 10, 100 x, y = 101, 11 x, y = 12, 102 x, y = 103, 13

15 (* synthesize *) module rules6 (Empty); D x2 Q +1 Reg#(int) x <- mkreg (10); Reg#(int) y <- mkreg (100); rule r1; x <= y + 1; D y2 Q +1 rule r2; y <= x + 1; (* descending_urgency = "r1, r2" *) clk $./rules6 -m 5 x, y = 10, 100 x, y = 101, 100 x, y = 101, 100 x, y = 101, 100 rule monitor; $display ("x, y = %0d, %0d ", x, y); endmodule

16 interface Rules7_Interface ; method int readvalue ; method Action setvalue (int newxvalue) ; method ActionValue#(int) increment ; endinterface (* synthesize *) module rules7 (Rules7_Interface); Reg#(int) x <- mkreg (0); method readvalue ; return x ; endmethod method Action setvalue (int newxvalue); x <= newxvalue ; endmethod method ActionValue#(int) increment ; x <= x + 1 ; return x ; endmethod endmodule

17 interface Rules7_Interface ; (* always_ready *) method int readresult ; (* always_enabled *) method Action setvalues (int newx, int newy, int newz) ; endinterface (* synthesize *) module rules7 (Rules7_Interface) ; Reg#(int) x <- mkreg (0) ; Reg#(int) y <- mkreg (0) ; Reg#(int) z <- mkreg (0) ; Reg#(int) result <- mkregu ; Reg#(Bool) b <- mkreg (False) ; rule toggle ; b <=!b ; // remaining internal signals assign x_mul_y d8 = x * y ; assign x_mul_z d5 = x * z ; rule r1 (b) ; result <= x * y ; rule r2 (!b) ; result <= x * z ; method readresult = result ; method Action setvalues (int newx, int newy, int newz) ; x <= newx ; y <= newy ; z <= newz ; endmethod endmodule

18

19 interface Rules8_Interface ; (* always_ready *) method int readresult ; (* always_enabled *) method Action setvalues (int newx, int newy, int newz) ; endinterface (* synthesize *) module rules8 (Rules8_Interface) ; Reg#(int) x <- mkreg (0) ; Reg#(int) y <- mkreg (0) ; Reg#(int) z <- mkreg (0) ; Wire#(int) t <- mkwire ; Reg#(int) result <- mkregu ; Reg#(Bool) b <- mkreg (False) ; rule toggle ; b <=!b ; rule computet ; if (b) t <= y ; else t <= z ; rule r1 (b) ; result <= x * t ; // inlined wires assign t$wget = b? y : z ; // remaining internal signals assign x_mul_t_wget d6 = x * t$wget ; method readresult = result ; method Action setvalues (int newx, int newy, int newz) ; x <= newx ; y <= newy ; z <= newz ; endmethod endmodule

20

21 High Level Synthesis Most work on high level synthesis focuses on the automation scheduling and allocation to achieve resource sharing. Perspective: high level synthesis in general applies to many aspects of converting high level descriptions into efficient circuits but there has been an undue level of effort on resource sharing in an ASIC context. Bluespec automates many aspects of scheduling (it makes scheduling composable) but resource usage is under the explicit control of the designer. For FPGA-based design this is often a better bit as a programming model.

22 Simple example with concurrency and shared resources cond0 cond1 cond x y Process 0: increments register x when cond0 Process 1: transfers a unit from register x to register y when cond1 Process 2: decrements register y when cond2 Process priority: 2 > 1 > 0 Each register can only be updated by one process on each clock. Priority: 2 > 1 > 0 Just like real applications, e.g.: Bank account: 0 = deposit to checking, 1 = transfer from checking to savings, 2 = withdraw from savings

23 cond0 cond1 cond2 CLK) begin if (cond2) y <= y 1; else if (cond1) begin y <= y + 1; x <= x 1; end Process priority: 2 > 1 > 0 x y CLK) begin if (cond2) y <= y 1; else if (cond1) begin y <= y + 1; x <= x 1; end Resource-access scheduling logic i.e., control logic Better scheduling if (cond0 &&!cond1) x <= x + 1; end if (cond0 && (!cond1 cond2) ) x <= x + 1; end * There are other ways to write this RTL, but all suffer from same analysis Fundamentally, we are scheduling three potentially concurrent atomic transactions that share resources. What if the priorities changed: cond1 > cond2 > cond0? What if the processes are in different modules?

24 With Bluespec, the design is direct cond0 cond1 cond x y Process priority: 2 > 1 > 0 (* descending_urgency = proc2, proc1, proc0 *) rule proc0 (cond0); x <= x + 1; rule proc1 (cond1); y <= y + 1; x <= x 1; rule proc2 (cond2); y <= y 1; Hand-written RTL: Explicit scheduling Complex clutter, unmaintainable BSV: Functional correctness follows directly from rule semantics (atomicity) Executable spec (operation-centric) Automatic handling of shared resource control logic Same hardware as the RTL

25 Now, let s make a small change: add a new process and insert its priority cond0 cond1 cond x cond3 Process priority: 2 > 3 > 1 > 0 y -1 2

26 Changing the Bluespec design cond0 cond1 cond x Pre-Change cond3 y -1 2 Process priority: 2 > 3 > 1 > 0 (* descending_urgency = "proc2, proc3, proc1, proc0" *) (* descending_urgency = proc2, proc1, proc0 *) rule proc0 (cond0); x <= x + 1; rule proc1 (cond1); y <= y + 1; x <= x 1; rule proc2 (cond2); y <= y 1; rule proc0 (cond0); x <= x + 1; rule proc1 (cond1); y <= y + 1; x <= x - 1; rule proc2 (cond2); y <= y - 1; x <= x + 1; rule proc3 (cond3); y <= y - 2; x <= x + 2;?

27 Changing the Verilog design cond0 cond1 cond2 Process priority: 2 > 3 > 1 > x y -1 2 cond3 Pre-Change CLK) begin if (!cond2 && cond1) x <= x 1; else if (cond0) x <= x + 1; if (cond2) y <= y 1; else if (cond1) y <= y + 1; end CLK) begin if ((cond2 && cond0) (cond0 &&!cond1 &&!cond3)) x <= x + 1; else if (cond3 &&!cond2)? x <= x + 2; else if (cond1 &&!cond2) x <= x - 1 if (cond2) y <= y - 1; else if (cond3) y <= y - 2; else if (cond1) y <= y + 1; end

28 Alternate RTL style (more common) cond0 cond1 cond Process priority: 2 > 1 > 0 x y (posedge clk) case ({cond0, cond1, cond2}) 3'b000: begin // nothing happens x <= x; y <= y; end 3'b001: begin //proc2 fires y <= y-1; end 3'b010: begin //proc1 x <= x-1; y <= y+1; end 3'b011: begin //proc2 fires (2>1) y <= y-1; end 3'b100: begin //proc0 x <= x+1; end 3'b101: begin //proc2 + proc0 x <= x+1; y <= y-1; end 3'b110: begin //proc1 (1>0) x <= x-1; y <= y+1; end 3'b111: begin //proc2 + proc0 x <= x+1; // NOTE subtle! y <= y-1; end endcase Combinatorial explosion Case 3 b111 is subtle Many repetitions of update actions ( cut-paste errors) cf. WTO Principle (Write Things Once Gerard Berry) Difficult to maintain/extend Difficult to modularize

29 Late Specifications Late specification changes and feature enhancements are challenging to deal with. Micro-architectural changes for timing/area/performance, e.g.: Adding a pipeline stage to an existing pipeline Adding a pipeline stage where pipelining was not anticipated Spreading a calculation over more clocks (longer iteration) Moving logic across a register stage (rebalancing) Restructuring combinational clouds for shallower logic Fixing bugs Bluespec makes it easier to try out multiple macro/micro-architectures earlier in the design cycle

30 Why Rule atomicity improves correctness Correctness is often couched (formally or informally) as an invariant E.g., # ingress packets # egress packets == packet-count register value Rule atomicity improves thinking about (and formally proving) invariants, because invariants can be verified one rule at a time In contrast, in RTL and thread models, must think of all possible interleavings cf. The Problem With Threads, Edward A. Lee, IEEE Computer 39(5), May 2006, pp

31 Bank Account: Key Benefits Executable specifications Rapid changes But, with fine-grained control of RTL: Define the optimal architecture/microarchitecture Debug at the source OR RTL level designer understands both The Quality of Results (QoR) of RTL!

32 A more complex example, from CPU design Speculative, out-of-order Many, many concurrent activities Register File Fetch FIFO Decode Branch FIFO Re- Order Buffer (ROB) FIFO FIFO FIFO FIFO ALU Unit MEM Unit FIFO FIFO FIFO FIFO Instruction Memory Data Memory

33 Many concurrent actions on common state: nightmare to manage explicitly Get operands for instr Register File Writeback results Empty Waiting E W E Re-Order Buffer State Instruction Operand 1 Operand 2 Result Instr - V - V - - Decode Unit Put an instr into ROB Head Tail E W W W W E E Instr - V - V - - Instr A V 0 V 0 - Instr B V 0 V 0 - Instr C V 0 V 0 - Instr D V 0 V 0 Instr - V - V - - Instr - V - V Get a ready ALU instr Put ALU instr results in ROB ALU Unit(s) Resolve branches E E E E E E Instr - V - V - - Instr - V - V - - Instr - V - V - - Instr - V - V - - Instr - V - V - - Instr - V - V - - Get a ready MEM instr Put MEM instr results in ROB MEM Unit(s) E E Instr - V - V Instr - V - V - -

34 In Bluespec..you can code each operation in isolation, as a rule..the tool guarantees that operations are INTERLOCKED (i.e. each runs to completion without external interference) Branch Resolution Commit Instr Write results to register Write Back Results file to ROB (or allow memory write for store) Write back results to instr result Set to Empty Dispatch Instr Write back to all waiting Increment head pointer Mark instruction tags Insert Instr in ROB dispatched Set to done Put instruction in first Forward to appropriate available slot unit Increment tail pointer Get source operands - RF <or> prev instr

35 cond0 cond1 cond Process priority: 2 > 1 > 0 x y Which one is correct? CLK) begin if (!cond2 && cond1) x <= x 1; else if (cond0) x <= x + 1; if (cond2) y <= y 1; else if (cond1) y <= y + 1; end CLK) begin if (!cond2 cond1) x <= x 1; else if (cond0) x <= x + 1; if (cond2) y <= y 1; else if (cond1) y <= y + 1; end What s required to verify that they re correct? What if the priorities changed: cond1 > cond2 > cond0? What if the processes are in different modules?

36 Some Verilog solutions cond0 cond1 cond2 Which one is correct? x y CLK) begin if (!cond2 && cond1) x <= x 1; else if (cond0) x <= x + 1; if (cond2) y <= y 1; else if (cond1) y <= y + 1; end Process priority: 2 > 1 > 0 CLK) begin if (!cond2 cond1) x <= x 1; else if (cond0) x <= x + 1; if (cond2) y <= y 1; else if (cond1) y <= y + 1; end Functional code and scheduling code are deeply (inextricably) intertwined. What s required to verify that they re correct? What if the priorities changed: cond1 > cond2 > cond0? What if the processes are in different modules?

37 Finite State Machines in Bluespec for makigncomposable, parallel, nested, suspendable/abortable FSMs sequencing if-then-else sequential loops parallel FSMs (fork-join) hierarchy (with suspend and abort) fsm fsm fsm fsm fsm fsm fsm fsm fsm fsm Enables exponentially smaller descriptions compared to flat FSMs Features: FSMs automatically synthesized Complex FSMs expressed succinctly FSM actions have same atomic semantics as BSV rule bodies Well-behaved on shared resources no surprises Standard BSV interfaces and BSV s higher-order functions can write your own FSM generators 37 This powerful capability is enabled by higher-order functions, polymorphic types, advanced parameterization and atomic transactions

38 FSM example (from testbench stimulus section) Stmt s = seq action rand_packets0.init; rand_packets1.init; endaction par for (j0 <= 0; j0 < n; j0 <= j0 + 1) action let pkt0 <- rand_packets0.next; switch.ports[0].put (pkt0); endaction for (j1 <= 0; j1 < n; j1 <= j1 + 1) action let pkt1 <- rand_packets1.next; switch.ports[1].put (pkt1); endaction endpar drain_switch; endseq; FSM fsm <- mkfsm (s); 38 rule go; s.start; Basic FSM statements are Actions, just like rule bodies, and have exactly the same atomic semantics. Thus, BSV FSMs are well-behaved with respect to concurrent resource contention and flow control.

39 Strong support for multiple clock and reset domains Rich and mature support for MCD (multiple clock domains and resets) Clock is a first-class data type Cannot accidentally mix clocks and ordinary signals Strong static checking ensures that it is impossible to accidentally cross clock domain boundaries (i.e., without a synchronizer) No need for linting tools to check domain discipline Clock manipulation Clocks can be passed in and out of module interfaces Library of clock dividers and other transformations Module instantiation can specify an alternative clock (instead of inheriting parent s default clock) (Similarly: Reset and reset domains) 39

40 Synthesis of Atomic Actions Compute Predicates for each rule p 1 p 2 p 3 scheduler Select maximal subset of applicable rules state read Predicates computed for each rule with a combinational circuit f 1 f 2 f 3 enabled rules Compute next state for each rule d 1 d 2 Selector Mux s & priority encoders update Potential update functions d 3

41 Key Issue: How to select to maximal subset of rules for firing? Two rules R1 and R2 can execute simultaneously if they are conflict free i.e. R1 and R2 do not update the same state; and Neither R1 or R2 do not read the that the other updates ( sequentially composable rules)

42 Rules of Rules (The Details 1-5/10) 1. Rules are atomic: rules fire completely or not at all, and you can imagine that nothing else happens during their execution. 2. Explicit and implicit conditions may prevent rules from firing. 3. Every rule fires exactly 0 or 1 times every cycle (at this point in our product's history anyway ;) 4. Rules that conflict in some way may fire together in the same cycle, but only if the compiler can schedule them in a valid order to do so -- that is, where the overall effect is as if they had happened one at at time as in (1) above. 5. Rules determine if they are going to fire or not before they actually do so. They are considered in their order of "urgency" (by a "greedy algorithm"): they "will fire" if they "can fire" and are not prevented by a conflict with a rule which has been selected already. It's OK to think of this phase as being completed (except for wires) before any rules are actually executed. This is what "urgency" is about.

43 Rules of Rules (The Details 6-10/10) 6. After determining which rules are going to fire, the simulator can then schedule their execution. (In hardware it's all done by combinational logic which has the same effect.) Rules do not need to execute in the same order as they were considered for deciding whether they "will fire". For example rule1 can have a higher urgency than rule2, but it is possible that rule2 executes its logic before rule1. Urgency is used to determine which rules "will fire. Earliness defines the order they fire in. 7. All reads from a register must be scheduled before any writes to the same register: any rule which reads from a register must be scheduled "earlier" than any other rule which writes to it. 8. Constants may be "read" at any time; a register *might* have a write but no read. 9. The compiler creates a sequence of steps, where each step is essentially a rule firing. Its inputs are valid at the beginning of the cycle, its outputs are valid at the end of the cycle. Data is not allowed to be driven "backwards" in the schedule: that is, no action may influence any action that happened "earlier" in the cycle. This would go against causality, and constitutes a "feedback" path that the compiler will not allow. 10. If the compiler is not told otherwise, methods have higher urgency than rules, and will execute earlier than rules, unless there's some reason to the contrary. There is a compiler switch to flip this around and make rules have higher urgency.

44 (* synthesize *) module rules9 (Empty) ; The Swap Conundrum Reg#(int) x <- mkreg (12) ; Reg#(int) y <- mkreg (17) ; rule r1 ; x <= y ; rule r2 ; y <= x ; $./rules9 -m 5 x, y = 12, 17 x, y = 12, 12 x, y = 12, 12 x, y = 12, 12 rule monitor ; $display ("x, y = %0d, %0d", x, y) ; endmodule

45 (* synthesize *) module rules9 (Empty) ; The Swap Conundrum Reg#(int) x <- mkreg (12) ; Reg#(int) y <- mkreg (17) ; rule r1 ; x <= y ; rule r2 ; y <= x ; rule r1 (tick 1) x._write (y._read ()) y read x write rule r2 (tick 2) y._write(x._read()) x read y write PROBLEM: register x must read before write rule monitor ; $display ("x, y = %0d, %0d", x, y) ; endmodule

46 (* synthesize *) module rules10 (Empty) ; Reg#(int) x <- mkreg (12) ; Reg#(int) y <- mkreg (17) ; rule r ; x <= y ; y <= x ; rule monitor ; $display ("x, y = %0d, %0d", x, y) ; endmodule $./rules10 -m 5 x, y = 12, 17 x, y = 17, 12 x, y = 12, 17 x, y = 17, 12 Schedule wise, step 1 reads x and y at the beginning and writes x and y at the end.

47 Wires In Bluespec from a scheduling perspective registers and wires are dual concepts. In one cycle all register reads must execute before register writes. In one cycle a wire must be written to (at most once) before it is read (any number of times).

48 Rules of Wires Wires truly become wires in hardware: they do not save state between cycles (compare to signal in VHDL). A wire s schedule requires that it be written before it is read (as opposed to a register that is read before it is written). A wire can not be written more than once in a cycle.

49 (* synthesize *) module rules11 (Empty) ; Reg#(int) x <- mkreg (12) ; Reg#(int) y <- mkreg (17) ; Wire#(int) xwire <- mkwire; rule r1 ; x <= y ; rule r2 ; y <= xwire ; $./rules11 -m 5 x, y = 12, 17 x, y = 17, 12 x, y = 12, 17 x, y = 17, 12 rule drivex ; xwire <= x ; rule monitor ; $display ("x, y = %0d, %0d", x, y) ; endmodule

50 (* synthesize *) module rules11 (Empty) ; Reg#(int) x <- mkreg (12) ; Reg#(int) y <- mkreg (17) ; Wire#(int) xwire <- mkwire; rule r1 ; x <= y ; rule r2 ; y <= xwire ; rule drivex ; xwire <= x ; $ cat rules11.sched === Generated schedule for rules11 === Rule schedule Rule: monitor Predicate: True Blocking rules: (none) Rule: drivex Predicate: True Blocking rules: (none) Rule: r2 Predicate: xwire.whas Blocking rules: (none) Rule: r1 Predicate: True Blocking rules: (none) Logical execution order: monitor, drivex, r1, r2 rule monitor ; $display ("x, y = %0d, %0d", x, y) ; endmodule ======================================= Question: is monitor, drivex, r2, r1 a valid schedule?

51 Wire Implements Reg interface (_read and _write methods). Implicit condition: it not ready if it has not been written In any cycle if there is no write to a wire then any rule that reads that wire is blocked (it can not fire).

52 (* synthesize *) module rules12 (Empty) ; Reg#(int) y <- mkreg (17) ; Reg#(int) count <- mkreg (0) ; Wire#(int) x <- mkwire; rule producer ; if (count % 3 == 0) x <= count ; rule consumer ; y <= x ; $display ("cycle %0d: y set to %0d", count, x) ; rule counter ; count <= count + 1 ; endmodule $./rules12 -m 9 cycle 0: y set to 0 cycle 3: y set to 3 cycle 6: y set to 6

53 DWire A Wire with a default value. A Dwire is always ready. If there is a write to a DWire in a cycle then just like a Wire it assumes that value. If there is no write to a DWire in a cycle it assumes a default value (given at instantiation time).

54 (* synthesize *) module rules13 (Empty) ; Reg#(int) y <- mkreg (17) ; Reg#(int) count <- mkreg (0) ; Wire#(int) x <- mkdwire (42); rule producer ; if (count % 3 == 0) x <= count ; rule consumer ; y <= x ; $display ("cycle %0d: y set to %0d", count, x) ; rule counter ; count <= count + 1 ; endmodule $ cycle 1: y set to 42 cycle 2: y set to 42 cycle 3: y set to 3 cycle 4: y set to 42 cycle 5: y set to 42 cycle 6: y set to 6 cycle 7: y set to 42

55 BypassWire Closest thing to a wire in Verilog. A BypassWire is always ready. Rather than having a default value the compiler must be able to statically determine that this wire is driven on every cycle.

56 FIFOs Lots and lots of FIFOs provided in FIFO, FIFOF, SpecialFIFOs libraries Examples (2 and 4 element FIFOs): FIFO#(UInt#(8)) myfifo <- mkfifo; FIFO#(UInt#(8)) biggerfifo <- mksizedfifo(4); Example BypassFIFO (1 storage element, data passes straight through if enq and deq on same cycle when empty) FIFO#(UInt#(8)) bypassfifo <- mkbypassfifo; Basic interfaces: enq(value) // enqueue value first // returns first element of fifo deq // dequeue

57 import FIFO::*; (* synthesize *) module rules14 (Empty) ; Reg#(int) count <- mkreg (0) ; FIFO#(int) fifo <- mksizedfifo (30); rule producer (count < 5) ; fifo.enq (count*3) ; $display ("cycle %0d: enqeuing value %d", count, count*3) ; rule consumer (count > 5) ; int x = fifo.first ; fifo.deq ; $display ("cycle %0d: deqeued value %0d", count, x) ; rule counter ; count <= count + 1 ; endmodule $./rules14 -m 20 cycle 0: enqeuing value 0 cycle 1: enqeuing value 3 cycle 2: enqeuing value 6 cycle 3: enqeuing value 9 cycle 4: enqeuing value 12 cycle 6: deqeued value 0 cycle 7: deqeued value 3 cycle 8: deqeued value 6 cycle 9: deqeued value 9 cycle 10: deqeued value 12

58 import FIFO::*; (* synthesize *) module rules15 (Empty) ; Reg#(int) count <- mkreg (0) ; FIFO#(int) fifo <- mksizedfifo (30); rule producer (count < 5) ; fifo.enq (count*3) ; $display ("cycle %0d: enqeuing value %0d", count, count*3) ; rule consumer (count < 5) ; int x = fifo.first ; fifo.deq ; $display ("cycle %0d: deqeued value %0d", count, x) ; rule counter ; count <= count + 1 ; endmodule

59 import GetPut::* ; import Connectable::* ; module mkproducer (Get#(int)) ; Reg#(int) i <- mkreg (0) ; rule incrementi ; i <= i + 1 ; method ActionValue#(int) get () ; return i ; endmethod endmodule: mkproducer (* synthesize *) module mkconnectableexample(empty) ; Get#(int) p <- mkproducer ; Put#(int) c <- mkconsumer ; mkconnection (p, c) ; endmodule: mkconnectabletest module mkconsumer (Put#(int)) ; Wire#(int) i <- mkwire ; rule report ; $display ("mkconsumer %d", i) ; Higher Order Types p and c are methods which are passed as arguments method Action put (int x) ; i <= x ; endmethod endmodule: mkconsumer

60 request response request response request response ServerFarm Information Flow ServerFarm DividerServer DividerServer

61 Conclusions Bluespec: provides cleaner interfaces quicker to create large systems from libraries of components easier to refine design creates most of the control for you (unless you don t want it to) less likely to get it wrong! has strong typing helps remove bugs provides powerful static elaboration