One means to control a simulation is to instantiate a counter at the top level, and key actions and possibly values from the counter values. In the example below, we setup a 16 bit counter, which is then used to start the VCD dumping, rule init, end the simulation rule stop, and control some action, rule action1. There is one additional rule, which constantly increments the count -- rule count.

// parameterized module -- a common module for testing all dut
// provided they provide the same interface -- type Pusher module push_tester#(Pusher dut_ifc) ( Empty );

   // a counter for simulation
   Reg #(Bit#(16)) count <- mkReg (0) ; // make a register with a 0 reset value
    ...
   // Start dumping
   rule init (count == 0); 
     $dumpvars() ; 
   endrule
 
   // keep counting  
   rule counting ;
     count <= count + 1;
   endrule 
 
   // finish simulation
   rule stop (count > 300 ); 
     $finish(1) ;
   endrule 
 
   rule action1 (count < 300) ; 
     // call the actions on the interface under test
     dut_ifc.act1() 
   endrule 
 
... 
endmodule // push_tester

Notice that this example also uses a module parameter of type interface Pusher. That is this module uses another interface as its parameter.

This can be invoked as shown below.

(* synthesize *)
module tst_fifo( Empty ); 
  
   Pusher dut1 <- mktestpush_fifo i_dut1 ;

   Empty i1 <- push_tester ( dut1 ) ;

endmodule

The top-level interface is "Empty", that is, it contains only a clock and reset line in the synthesized version. For modules with "Empty" interfaces, Bluespec provides a test driver module, one which applies a reset, and then drives the clock indefinitely. The module is located in $BLUESPECDIR/Verilog/main.v and can be invoked by vcs using the following command-line:

vcs $BLUESPECDIR/Verilog/main.v +define+TOP=tst_fifo +libext+.v -y $BLUESPECDIR/Verilog/ *.v