Testbench in verilog ps and human interactions don't mix

[Giuseppe Marullo]

Hi all,
I am testing a fairly slow design ( a IAMBIC keyer) and while I am
dealing with slow signals (up to 120 WPM, about 10ms minimum resolution)
I would like to perform very precise measurements about the timing.

I have on the real board a 12/24/48Mhz clock and first surprise I got is
that I cannot "feed" this precise clock to the design, because the
period of a 12MHz is 83.3 periodic ns.

I switched to ps to give more "digits" but ps is a way too small for any
other signal I want to handle so I can't specify "human" signals like
paddle activation (about 8ms) using # because it overflows.

BTW, even in ps is still not totally accurate because it does not seem
possible to specify decimals.

So, is there a neat way to generate a testbench with exactly 12MHz clock
and use at the same time a time unit in the micro second range?
TIA.

Giuseppe Marullo

 

[Allan Herriman]

On Sat, 20 Aug 2011 11:26:51 +0200, Giuseppe Marullo wrote:

Hi all,
I am testing a fairly slow design ( a IAMBIC keyer) and while I am
dealing with slow signals (up to 120 WPM, about 10ms minimum resolution)
I would like to perform very precise measurements about the timing.

I have on the real board a 12/24/48Mhz clock and first surprise I got is
that I cannot "feed" this precise clock to the design, because the
period of a 12MHz is 83.3 periodic ns.

I switched to ps to give more "digits" but ps is a way too small for any
other signal I want to handle so I can't specify "human" signals like
paddle activation (about 8ms) using # because it overflows.

BTW, even in ps is still not totally accurate because it does not seem
possible to specify decimals.

So, is there a neat way to generate a testbench with exactly 12MHz clock
and use at the same time a time unit in the micro second range?
TIA.

Giuseppe Marullo

It is not possible to represent a 12MHz clock in a simple manner with the
simulator resolution set to microseconds.

It is possible to generate a clock with a frequency of 12MHz provided
that the timing resolution of the simulator is 10ns or smaller.

(Note, typically simulator resolutions can only be set to 1 fs, 10 fs, ...
1 ns, 10 ns, 100 ns etc.)

I just simulated this code with a 1 ns simulator resolution, and it
produced a 12 MHz clock. This frequency is a long term average though;
in the short term there will be jitter as high as 1 ns due to the timing
resolution.


`timescale 1 ns / 1 ns

module twelve_MHz
(
output reg clk = 0
);

initial forever begin

#41 clk <= !clk;
#42 clk <= !clk;
#42 clk <= !clk;

end

endmodule


Consider what I've done: the times between transitions (i.e. half
periods) are, in sequence, 41ns, 42ns, 42ns, 41ns, 42ns, 42ns, etc. The
long term average is 41.667 ns, giving exactly 12MHz.

Had the simulator resolution been 10 ns, we would have needed a repeating
sequence like:
40ns, 40ns, 40ns, 40ns, 40ns, 50ns.

This is known as a fractional divider, and there are many ways of
designing these.

For simulation purposes I use a module that takes a real parameter to
specify the desired frequency in Hz. It works for frequencies up to half
of the reciprocal of the timing resolution of the simulator.

Regards,
Allan

 

[Giuseppe Marullo]

This is known as a fractional divider, and there are many ways of
designing these.

For simulation purposes I use a module that takes a real parameter to
specify the desired frequency in Hz. It works for frequencies up to half
of the reciprocal of the timing resolution of the simulator.

Regards,
Allan

Allan, many thanks for your answer. I still used the ps resolution and
came up with a:

//Clock generation
always
begin
#41666 fx2_clk = !fx2_clk;
#41667 fx2_clk = !fx2_clk;
#41667 fx2_clk = !fx2_clk;
end

That would lower the jitter even more.

It works perfectly and now I have very good and round timings in my
simulator.

Could you tell me more about the module you mentioned?

Thanks in advance.

Giuseppe Marullo

 

[Allan Herriman]

On Mon, 22 Aug 2011 00:58:17 +0200, Giuseppe Marullo wrote:

This is known as a fractional divider, and there are many ways of
designing these.

For simulation purposes I use a module that takes a real parameter to
specify the desired frequency in Hz. It works for frequencies up to
half of the reciprocal of the timing resolution of the simulator.

Regards,
Allan

Allan, many thanks for your answer. I still used the ps resolution and
came up with a:

//Clock generation
always
begin
#41666 fx2_clk = !fx2_clk;
#41667 fx2_clk = !fx2_clk;
#41667 fx2_clk = !fx2_clk;
end

That would lower the jitter even more.

It works perfectly and now I have very good and round timings in my
simulator.

It seems like you have the hang of things.

Could you tell me more about the module you mentioned?

I have both Verilog and VHDL "precision_clock_generator" modules that
I've been using for about a decade now.

I also have a "precision_vcxo" (VHDL only, 'cause Verilog is too stupid
to allow ports of type real for the control voltage) that's handy for
simulating certain types of PLLs.

I may eventually get around to cleaning them up for publication, probably
on opencores.

The interface looks roughly like this:

module precision_clock_generator
#(
parameter FREQUENCY // frequency in Hz, (real)
)
(
input enable, // runs when this input is high or open
output clk_p, // main clock output
output clk_n, // inverse of clk_p
);

Basically it just models one of those 4 or 6 pin crystal oscillators and
uses various techniques to ensure that it produces the exact frequency
requested, with the minimum possible amount of jitter.

For most testbenches, the simple and obvious way of generating clocks in
either HDL works fine, but there are times when you really need the right
frequency and these modules help with that.

Regards,
Allan