Rule-based hardware generation (BlueSpec)

Recently BlueSpec System Verilog has successfully raised the level of abstraction in RTL design:

• A Bluespec design is expressed as a list of declarative rules,
• Shared variables are mostly replaced with one-place FIFO buffers with automatic handshaking,
• Rules are allocated a static schedule at compile time and some that can never fire are reported,
• The current tight control of clock cycle (time/space folding) might be relaxed by future compilation strategies.
• The wiring pattern of the whole design is generated using an embedded functional language (like Lava).

The term `wiring' above is used in the sense of TLM models: binding initiators to target methods.

»LINK: Small Examples»Toy BSV Compiler (DJG) First basic example: two rules: one increments, the other exits the simulation. This example looks very much like RTL: provides an easy entry for hardware engineers.

module mkTb (Empty);

   Reg#(int) x <- mkReg (23);

   rule countup (x < 30);
      int y = x + 1;
      x <= x + 1;
      $display ("x = %0d, y = %0d", x, y);
   endrule

   rule done (x >= 30);
      $finish (0);
   endrule

endmodule: mkTb

Second example uses a pipeline object that could have aribtrary delay. Sending process is blocked by implied handshaking wires (hence less typing than Verilog) and in the future would allow the programmer or the compiler to retime the implementation of the pipe component.

module mkTb (Empty);

   Reg#(int) x    <- mkReg ('h10);
   Pipe_ifc  pipe <- mkPipe;

   rule fill;
      pipe.send (x);
      x <= x + 'h10;
   endrule

   rule drain;
      let y = pipe.receive();
      $display ("    y = %0h", y);
      if (y > 'h80) $finish(0);
   endrule
endmodule

But, behavioural expression using a conceptual thread is also useful to have, so BlueSpec has a behavioural sub-language compiler built in.