#1033 possible false clocking

[John Wehle]

The supplied file is a by 7.5 clock divider implemented as
a by 1.5 clock divider followed by a by 5 clock divider.

Running it shows:

iverilog -g2009 -o iv_tb iv_tb.v
vvp iv_tb
VCD info: dumpfile iv_tb.vcd opened for output.
cycles expected got
15 2 4

The problem being 15 clock cycles divided by 7.5 should yield 2.

Using gtkwave to view rst, rclk, clk_1_5, k, and dclk from iv_tb.vcd
we see:

clk_1_5 looks like it cycles correctly after rst has occurred.

k looks incorrect. Specifically we see it correctly change state
after rst on the posedge of clk_1_5, however it then also changes
state on the edges of rclk. This is a bit strange since k is modified
inside of:

always @(posedge clk_1_5, posedge rst)

so it shouldn't be directly affected by rclk.

I'll note that the article:

Unusual Clock Dividers
Peter Alfke
Xilinx Applications

used to implement the 1.5 clock divider does say that while the
circuit works fine it can cause problems for simulators.

Thoughts or work arounds?

-- John

[Martin Whitaker]

The design generates glitches on clk_1_5. Because there are no delays, you don't see these in gtkwave. There are two sources of glitches:

1. Assigning clk_1_5 = rclk and then reassigning it in the case statement can generate a glitch. This will be enough to trigger the @(posedge clk_1_5). You can fix that by removing the initial assignment and adding a default clause in the case statement.

2. The non-blocking assignments to a and b cause a and b to change in a different simulation time delta to rclk. You can see this in gtkwave by adding an intra-assignment delay to the assignments, simulating a real clk->q delay.

This design is unsafe in reality as well as in simulation.

[John Wehle]

It would be useful if the perceived glitch on clk_1_5 was visible in gtkwave.

The circuit is intended to be implemented by a FPGA whose combination logic
block is guarenteed not to glitch if certain critiera is meet. This fact is being
leveraged by the technical note I mentioned in how they implemented the divider.

Making the change you suggested to using a default clause in the case block does
eliminate one of the glitches perceived by the simulator.

Do you have a suggestion on how to let the simulator know that the other glitch
can't happen in this particular instance (the combination logic block sees rclk go
high prior to b going low and will not glitch).

[Martin Whitaker]

Add a small delay before the case statement, e.g. #0.01, ensuring all inputs to the combinatorial block are stable before evaluating the output. That's not exactly simulating the FPGA behaviour, but it achieves the same end. You'll need to add a timescale to your design for fractional delays to work.

You'd have to talk to the gtkwave author about displaying glitches. Their presence can be detected in the VCD file. If you run your original code, a value is output for clk_1_5 every time step. Once the glitches are removed, a value is output only when there's a change.

[John Wehle]

Adding a small delay to the case statement does produce the desired results.

I'll see about taking up the gtkwave issue over with the gtkwave people.

Thanks for your time and your guidance.

-- John

[Martin Whitaker]

Closing, as I believe the compiler is behaving correctly.