Anywhere to find the description of cycle based simulator
In the following example, I can tell the event schedule and evaluation steps in a event based simulator. But for Verilator or any cycle based simulator, any document to tell how this is being processed? Especially the gated clock part.
By the way, I agree this is not a good code that gated_clk is not clean. In event based simulator, the gated_clk will have a glitch when GC changes from 1 to 0. But the glitch will not happen in Verilator and other cycle based simulator.
always @(posedge clk) GC <= d1;
assign gated_clock = GC & clk;
always @(posedge gated_clk) out <= d2;
RE: Anywhere to find the description of cycle based simulator - Added by Wilson Snyder 10 months ago
This isn't well documented, certainly something for us to improve.
Basically it works as you would expect gates to work, e.g. in your example if you built this of gates, the gated clock has a gate delay between its clock and the input, so signals can race between the flops. To avoid this use the clock_enable attribute described in the manual which makes the gater basically have no delay.
The general understand of the CBS algorithm is:
1. simulate all combinational elements;
2. simulate all sequential elements;
3. generate primary output values using primary input values and the current values of sequential elements;
Back to my example:
always @(posedge clk) GC <= d1; assign gated_clock = GC & clk; always @(posedge gated_clk) out <= d2;
Assume at time t - 1 :
d1 = 1, GC = 0;
Then at time t:
1. gated_clock = gc & clk ; // here gc should be the old value, so we should not see gated_clock change from 0 to 1?
2. GC <= d1; out <= d2 // so the second FF should not be latched at time t since gated_clock does not have the posedge?
Point is, if CBS is just like Event Based Simulator, after NBA is done, it also can issue another events for blocking code ( assign gated_clk = ... in this case) to run again?
Or simply evaluate twice without advance the time?
Verilator figures out the logic graph of the code, basically as a cone, and starts from inputs evaluating what that needs, then working towards flops. If a signal from a flop or combo loop makes a clock we repeat the process (without advancing the time). See the _eval code in a generated model.