Verilator

After looking at the _eval event loop generated by verilator , I don't see how generated clocks could work consistently when there is feedback in the design. There seems to be a definite ordering of the events inside eval loop and I see my different generated clocks in there. I apologize if I misunderstood the internal workings of the verilator in some way.

To support latches and gated clocks I think verilator needs support for an expanded event queue. Maybe not as elaborate as the Verilog standard, but at least support for "non-blocking" events. Let me know if I can help out in any way. You don't want me touching the code:-) but I can definitely help in testing and brain storming.

The verilog standard event queue.

1.) Events that occur at the current simulation time and can be processed in any order. These are the active events. 2) Events that occur at the current simulation time, but that shall be processed after all the active events are processed. These are the inactive events. 3) Events that have been evaluated during some previous simulation time, but that shall be assigned at this simulation time after all the active and inactive events are processed. These are the nonblocking assign update events. 4) Events that shall be processed after all the active, inactive, and nonblocking assign update events are processed. These are the monitor events. 5) Events that occur at some future simulation time. These are the future events. Future events are divided into future inactive events, and future nonblocking assignment update events.

First, using the clock_enable pragma is fine. I updated the docs for next release.

You're right how the event queue works for an event simulator. However Verilator instead computes the event ordering internally then optimizes; this is a lot more complicated (and bug prone) but more than 2x faster.

As for your problem, can you reduce it to a little testcase as described in the manual and post it (search for t_EXAMPLE)? It ouldn't be shocking if there is a latch bugs, as latches now days are relatively rarely encountered.

Hi Wilson,

Thanks for the quick reply. I find it ironic (and quite funny) that your open source support is faster than most commercial EDA support:-)

I will work on a test case packaged up the right way. Here is the code of the test case. (I verified it with Icarus). There is a race at flop3 when handing off data from flop2.

Is there a better way of dealing with generated clocks? In this case, driving all clocks at the interface is not an option.

TESTCASE:

/*verilator lint_off UNOPTFLAT*/
/*verilator lint_off COMBDLY*/

reg             en1_sh;
reg             en2_sh;

reg             flop1;
reg             flop2;
reg             flop3;

wire         clk1;
wire         clk2;
wire         clkdiv3;

always @(/*AS*/clk or flop1)
  if(~clk)
    en1_sh <=flop1;

always @(/*AS*/clk or flop2)
  if(~clk)
    en2_sh <=flop2;

assign   clkdiv3 = clk & en2_sh;

//Divide by 3 circuit
always @(posedge clk or posedge stim_reset)
  if(stim_reset)
    flop1  <= 1'b0;   
  else
    flop1  <= flop2;

always @(posedge clk or posedge stim_reset)
  if(stim_reset)
    flop2 <= 1'b0;
  else
    flop2 <= ~(flop1 | flop2);

always @(posedge clkdiv3 or posedge stim_reset)
  if(stim_reset)
    flop3 <= 1'b0;
  else
    flop3 <= flop2;