First clock period in generated testbench shorter than designed clock period

[Koen Raben]

Hi,

When generating a verilog testbench and a clock signal with a period of 20 ns the first half-period of the clock is set to 3 ns instead of the expected 10 ns. I have included the relevant part of the verilog code below. What is the cause of this deviating clock period and how would I be able to change it from my Clash description?

Any help is greatly appreciated!

Kind Regards,
Koen Raben

Verilog snippet:

// tbClockGen begin

  // pragma translate_off

  reg  clk_0;

  // 1 = 0.1ps

  localparam half_period = (200000 / 2);

  always begin

    // Delay of 1 mitigates race conditions (https://github.com/steveicarus/iverilog/issues/160)

    #1 clk_0 =  0 ;

    #30000 forever begin //<------------- Where does this number come from?

      if (~ (~ c$result_rec)) begin

        $finish;

      end

      clk_0 = ~ clk_0;

      #half_period;

      clk_0 = ~ clk_0;

      #half_period;

    end

  end

[Christiaan Baaij]

I define the period as the time between two active edges.

Looking at the generated code, it seems that you're using positive-edge triggered logic.

For a 20ns clock, The first active edge, going from 0 to 1, happens at 3.0001ns the second active edge happens at 23.0001ns, the third at 43.0001ns, etc.

So the period is definitely 20ns.

The 3ns was definitely picked arbitrarily.

But whether the first active edge happens at 0.0002ns (it must happen at time-step 2 (0.2ps) because of the mentioned race-condition avoidance) or at 3.0001ns doesn't really matter, no?

--
You received this message because you are subscribed to the Google Groups "Clash - Hardware Description Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clash-languag...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clash-language/23e971f8-bef0-4451-a2e0-ef5d48325ee9n%40googlegroups.com.

[Christiaan Baaij]

Is the time from simulation start until the first active edge being shorter than the period causing problems in a post-synthesis simulation?

If you have register models that checks stable values in the setup/hold window I can imagine that this would be a problem.

If so: can you raise an issue on https://github.com/clash-lang/clash-compiler/issues

[Koen Raben]

Hey Christiaan,

That is exactly the problem I ran into. In post-synthesis simulations the setup time is not long enough for all signals to become stable. 
I shall submit the issue.

Kind regards,
Koen Raben