verilator some problems in driving system verilog signals from cpp bench.

1. In order to practice cpp (c++) verification benches, with system verilog DPI, using a verilog DUT, I decided to download verilator and do some self study exercises.
   


2. When I drive input data with no delay, flip-flops in the DUT were not simulated correctly. Their output was set immediately (no sample i.e. one cycle delay). So I decided to put a one unit time delay, as shown in the waves below. This still did not solve the problem completely. Now I saw some combinatorial logic, inside the DUT, not behaving well. Their outputs were not updated, but only after the next clock rise edge, where it was too late. I solved it by registering the driven signals in the system verilog bench and then applying the registered ones to the DUT:
   
   
   1.   initial begin
   2.     Trd=1'b0;
   3.     Twr=1'b0;
   4.   end
   7.   //monitor fifo errors v2c DPI function
   8.   import "DPI-C" function integer f_ferr(integer ferr);
   10.   //drive using c2v DPI function
   11.   export "DPI-C" task t_gen_stim;
   12.   task t_gen_stim;
   13.     input bit trd;
   14.     input bit twr;
   16.    /*
   17.    if(trd || twr)
   18.    $display("task drive %d %d at %d", trd, twr, $time);
   19.    */
   21.    Trd=trd;
   22.    Twr=twr;
   23.   endtask
   24.   reg Trd, Twr;
   25.   reg qrd, qwr;
   27.   always @ (posedge clk) begin
   28.     qwr <= Twr;
   29.     qrd <= Trd;
   30.   end
   31. ...
   32.   pipe_fifo u_dut (
   33.    .clk(clk),
   34.    .rst(rst),
   35.    .clr(clr),
   36.    .rd(qrd), //fifo read
   37.    .wr(qwr), //fifo write
   38. ...





3. Another way round this issue was suggested by Mr Wilson Snyder:
   reg Trd /*verilator public_flat_rw @(negedge clk)*/;
   reg Twr /*verilator public_flat_rw @(negedge clk)*/;
   
   When I add that your test doesn't fail. This tells
   verilator when your DPI task may be changing the
   signals; see the man page. Verilator uses this to
   schedule the model; without such hints it assumes you
   only change them when the signals would otherwise
   change. (Or it would have to assume they could
   change anywhere which would be very slow.)
   

Home	some memory VHDL models my first experience with verilator.