issue with real datatype and $time system task in Verilog

S

SB

Guest
All,

Question on the use of the real datatype in Verilog:

I have the following Verilog testbench. (DUT has been removed for
clarity)
///////////////////////////////////////////////////////////////////////////
`timescale 1ps / 1ps
module tb_test ();

reg sig_in_tb;
real current_delay;
real time1;
real time2;
real sig_in_period;

initial
begin
time1 = 0.0;
time2 = 0.0;
sig_in_period = 0.0;
current_delay = 0.0;
sig_in_tb = 1'b0;

//#1000;
current_delay = 30000;
get_clock_period;
#400000;
current_delay = 20000;
get_clock_period;
#400000;
current_delay = 10000;
get_clock_period;
#400000;

$finish;
end

always
begin
sig_in_tb = #(current_delay) ~sig_in_tb;
end

task get_clock_period;
begin
@ (posedge sig_in_tb)
begin
time1 = $realtime;
end

@ (posedge sig_in_tb)
begin
time2 = $realtime;
end
sig_in_period=time2-time1;
end
endtask

endmodule
///////////////////////////////////////////////////////////////////////////

The above task, get_clock_period, is being used to capture the period
of the clock, sig_in_tb.
It does this by capturing the time for the first positive edge on the
clock,
then the time for the next positive edge and then captures the
difference
between the two timestamps and returns this to a testbench variable
called "sig_in_period".

This is not working, for all but the last frequency on sig_in_tb.

For the first two frequencies on sig_in_tb, i.e. for the first two
values on
current_delay, the time1 and time2 values are merely the simulation
timestamp.
This ramps up as the simulation progresses.

Only at the final current_delay value, i.e. the third frequency, do
the time1 and time2 variables
get assigned the timestamps of the first and second positive edges of
sig_in_tb
after current_delay is assigned 10000.

I am using the VerilogXL simulator for this.

How do I ensure that time1 and time2 are operating correctly?
Is this problem related to improper use of the real datatype?

Thanks in advance.
SB
 
On 28 July, 20:12, SB <paulsheeha...@yahoo.com> wrote:
All,

Question on the use of the real datatype in Verilog:

I have the following Verilog testbench. (DUT has been removed for
clarity)
///////////////////////////////////////////////////////////////////////////
`timescale 1ps / 1ps
module tb_test ();

reg sig_in_tb;
real current_delay;
real time1;
real time2;
real sig_in_period;

initial
begin
time1 = 0.0;
time2 = 0.0;
sig_in_period = 0.0;
current_delay = 0.0;
sig_in_tb = 1'b0;

//#1000;
current_delay = 30000;
get_clock_period;
#400000;
current_delay = 20000;
get_clock_period;
#400000;
current_delay = 10000;
get_clock_period;
#400000;

$finish;
end

always
begin
        sig_in_tb = #(current_delay) ~sig_in_tb;
end

task get_clock_period;
begin
@ (posedge sig_in_tb)
begin
       time1 = $realtime;
end

@ (posedge sig_in_tb)
begin
        time2 = $realtime;
end
       sig_in_period=time2-time1;
end
endtask

endmodule
///////////////////////////////////////////////////////////////////////////

The above task, get_clock_period, is being used to capture the period
of the clock, sig_in_tb.
It does this by capturing the time for the first positive edge on the
clock,
then the time for the next positive edge and then captures the
difference
between the two timestamps and returns this to a testbench variable
called "sig_in_period".

This is not working, for all but the last frequency on sig_in_tb.

For the first two frequencies on sig_in_tb, i.e. for the first two
values on
current_delay, the time1 and time2 values are merely the simulation
timestamp.
This ramps up as the simulation progresses.

Only at the final current_delay value, i.e. the third frequency, do
the time1 and time2 variables
get assigned the timestamps of the first and second positive edges of
sig_in_tb
after current_delay is assigned 10000.

I am using the VerilogXL simulator for this.

How do I ensure that time1 and time2 are operating correctly?
Is this problem related to improper use of the real datatype?

Thanks in advance.
SB
Click to expand...
The above issue also happens when time1 and time2 are assigned the
value of $time. See the following:

task get_clock_period;
begin
@ (posedge sig_in_tb)
begin
time1 = $time;
end

@ (posedge sig_in_tb)
begin
time2 = $time;
end
sig_in_period=time2-time1;
end
endtask
 
On Jul 28, 3:12 pm, SB <paulsheeha...@yahoo.com> wrote:

Looks to me like it is working fine. I added a $display in
get_clock_period to print out the value of sig_in_period each time,
and it printed 60000, 40000, 20000. That is twice your delay, as
expected. This was in Verilog-XL.
 
On Jul 29, 8:05 pm, sh...@cadence.com wrote:
On Jul 28, 3:12 pm, SB <paulsheeha...@yahoo.com> wrote:

Looks to me like it is working fine. I added a $display in
get_clock_period to print out the value of sig_in_period each time,
and it printed 60000, 40000, 20000. That is twice your delay, as
expected. This was in Verilog-XL.
Click to expand...

I now understand the reason for the fact that I was seeing the
ramp in the waveform viewer for sig_in_period, time1 and time2.
In the case of time1 and time2 these values matched the
simulation timestamp.

Using the $display system task, I have reasoned that the simulator
is returning the correct values for time1, time2 and sig_in_period
when I expect them and does not update the values until they are
assigned to again.
In between these assignment points, the waveform viewer is merely
representing the transition
between the assigned values of time1, time2 and sig_in_period with
a ramp (rather than a step, which I expected). This may be the
consequence
of the real datatype.

The ramp is not showing what the simulator says, but it is simply the
way that it
represents the change in time1, time2 and sig_in_period.

The values of time1, time2 and sig_in_period are level in the waveform
viewer for the last frequency because they are simply not assigned
to anymore after that.

Thank you for checking this.
SB
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top