Why are these two signals the same waveform?

R

Robert Willy

Guest
Hi,

When I simulate my test bench, it is a surprise that d_in0 and d_in have the
save waveform. From my impression on registered signals, d_in should have one
clock delay than d_in0. Could you explain it to me?


Thanks in advance.



initial
begin
repeat(10) @(posedge clk);
rst <= 1'b1;
@(posedge clk);
rst <= 1'b0;
repeat(5) @(posedge clk);
while (!$feof(x_in))
begin
x_read <= $fscanf(x_in,"%d\n",d_in0);
d_in <= d_in0;
@(posedge clk);
end
repeat(1000) @(posedge clk);
$fclose(x_in);
$fclose(x_out);
$stop;
end
 
On Thursday, 8/9/2018 9:41 PM, Robert Willy wrote:
Hi,

When I simulate my test bench, it is a surprise that d_in0 and d_in have the
save waveform. From my impression on registered signals, d_in should have one
clock delay than d_in0. Could you explain it to me?


Thanks in advance.



initial
begin
repeat(10) @(posedge clk);
rst <= 1'b1;
@(posedge clk);
rst <= 1'b0;
repeat(5) @(posedge clk);
while (!$feof(x_in))
begin
x_read <= $fscanf(x_in,"%d\n",d_in0);
d_in <= d_in0;
@(posedge clk);
end
repeat(1000) @(posedge clk);
$fclose(x_in);
$fclose(x_out);
$stop;
end
Click to expand...

x_read <= $fscanf(x_in,"%d\n",d_in0);

This line doesn't really do what you think it does. While it has a
non-blocking assignment to x_read, the side-effects of the fscanf call
including assigning a value to d_in0 happen immediately. So because
you assign d_in on the following line, it already takes on the new
value of d_in0. Reversing the order of the two lines should make
d_in have the delay you're expecting, but if any other clocked logic
uses d_in0, it could also have the same issue (I say could because
it is a race condition to use d_in0 in another clocked block).


--
Gabor
 
On Monday, August 13, 2018 at 2:47:42 AM UTC+5:30, Gabor wrote:
On Thursday, 8/9/2018 9:41 PM, Robert Willy wrote:
Hi,

When I simulate my test bench, it is a surprise that d_in0 and d_in have the
save waveform. From my impression on registered signals, d_in should have one
clock delay than d_in0. Could you explain it to me?


Thanks in advance.



initial
begin
repeat(10) @(posedge clk);
rst <= 1'b1;
@(posedge clk);
rst <= 1'b0;
repeat(5) @(posedge clk);
while (!$feof(x_in))
begin
x_read <= $fscanf(x_in,"%d\n",d_in0);
d_in <= d_in0;
@(posedge clk);
end
repeat(1000) @(posedge clk);
$fclose(x_in);
$fclose(x_out);
$stop;
end


x_read <= $fscanf(x_in,"%d\n",d_in0);

This line doesn't really do what you think it does. While it has a
non-blocking assignment to x_read, the side-effects of the fscanf call
including assigning a value to d_in0 happen immediately. So because
you assign d_in on the following line, it already takes on the new
value of d_in0. Reversing the order of the two lines should make
d_in have the delay you're expecting, but if any other clocked logic
uses d_in0, it could also have the same issue (I say could because
it is a race condition to use d_in0 in another clocked block).


--
Gabor
Click to expand...

Hai!

your expected behavior would be seen in waveform if you would have used:
d_in <= x;
d_in <= d_in0;


But, in your code, it is written:
x_read <= $fscanf(x_in,"%d\n",d_in0);
d_in <= d_in0;
@(posedge clk)
Click to expand...

Let me explain its behavior using Verilog Stratified queue.
In active queue: RHS of both statements gets evaluated in order.
i.e.,d_in0 of fscanf will be evaluated and then d_in0 of next statement.

Hence, we won't get any delay.
Reversing the order gives delay.
 
On Monday, August 13, 2018 at 2:47:42 AM UTC+5:30, Gabor wrote:
On Thursday, 8/9/2018 9:41 PM, Robert Willy wrote:
Hi,

When I simulate my test bench, it is a surprise that d_in0 and d_in have the
save waveform. From my impression on registered signals, d_in should have one
clock delay than d_in0. Could you explain it to me?


Thanks in advance.



initial
begin
repeat(10) @(posedge clk);
rst <= 1'b1;
@(posedge clk);
rst <= 1'b0;
repeat(5) @(posedge clk);
while (!$feof(x_in))
begin
x_read <= $fscanf(x_in,"%d\n",d_in0);
d_in <= d_in0;
@(posedge clk);
end
repeat(1000) @(posedge clk);
$fclose(x_in);
$fclose(x_out);
$stop;
end


x_read <= $fscanf(x_in,"%d\n",d_in0);

This line doesn't really do what you think it does. While it has a
non-blocking assignment to x_read, the side-effects of the fscanf call
including assigning a value to d_in0 happen immediately. So because
you assign d_in on the following line, it already takes on the new
value of d_in0. Reversing the order of the two lines should make
d_in have the delay you're expecting, but if any other clocked logic
uses d_in0, it could also have the same issue (I say could because
it is a race condition to use d_in0 in another clocked block).


--
Gabor
Click to expand...

Hai!

your expected behavior would be seen in waveform if you would have used:
d_in <= x;
d_in0 <= d_in;


But, in your code, it is written:
x_read <= $fscanf(x_in,"%d\n",d_in0);
d_in <= d_in0;
@(posedge clk)
Click to expand...

Let me explain its behavior using Verilog Stratified queue.
In active queue: RHS of both statements gets evaluated in order.
i.e.,d_in0 of fscanf will be evaluated and then d_in0 of next statement.

Hence, we won't get any delay.
Reversing the order gives delay.
 
On Monday, August 13, 2018 at 11:49:35 AM UTC-5, Y.V.V.Nagendra wrote:
On Monday, August 13, 2018 at 2:47:42 AM UTC+5:30, Gabor wrote:
On Thursday, 8/9/2018 9:41 PM, Robert Willy wrote:
Hi,

When I simulate my test bench, it is a surprise that d_in0 and d_in have the
save waveform. From my impression on registered signals, d_in should have one
clock delay than d_in0. Could you explain it to me?


Thanks in advance.



initial
begin
repeat(10) @(posedge clk);
rst <= 1'b1;
@(posedge clk);
rst <= 1'b0;
repeat(5) @(posedge clk);
while (!$feof(x_in))
begin
x_read <= $fscanf(x_in,"%d\n",d_in0);
d_in <= d_in0;
@(posedge clk);
end
repeat(1000) @(posedge clk);
$fclose(x_in);
$fclose(x_out);
$stop;
end


x_read <= $fscanf(x_in,"%d\n",d_in0);

This line doesn't really do what you think it does. While it has a
non-blocking assignment to x_read, the side-effects of the fscanf call
including assigning a value to d_in0 happen immediately. So because
you assign d_in on the following line, it already takes on the new
value of d_in0. Reversing the order of the two lines should make
d_in have the delay you're expecting, but if any other clocked logic
uses d_in0, it could also have the same issue (I say could because
it is a race condition to use d_in0 in another clocked block).


--
Gabor

Hai!

your expected behavior would be seen in waveform if you would have used:
d_in <= x;
d_in0 <= d_in;


But, in your code, it is written:
x_read <= $fscanf(x_in,"%d\n",d_in0);
d_in <= d_in0;
@(posedge clk)

Let me explain its behavior using Verilog Stratified queue.
In active queue: RHS of both statements gets evaluated in order.
i.e.,d_in0 of fscanf will be evaluated and then d_in0 of next statement.

Hence, we won't get any delay.
Reversing the order gives delay.
Click to expand...
Thanks Gabor and Nagendra. I also get my answer for the leading '0' bits
number. It is a simple combinational logic, no easier trick there.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top