EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

Why are these two signals the same waveform?

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - Verilog Language - Why are these two signals the same waveform?

Robert Willy
Guest

Fri Aug 10, 2018 2:45 am   



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

Gabor
Guest

Sun Aug 12, 2018 10:45 pm   



On Thursday, 8/9/2018 9:41 PM, Robert Willy wrote:
Quote:
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

Y.V.V.Nagendra
Guest

Mon Aug 13, 2018 6:45 pm   



On Monday, August 13, 2018 at 2:47:42 AM UTC+5:30, Gabor wrote:
Quote:
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_in <= d_in0;


But, in your code, it is written:
x_read <= $fscanf(x_in,"%d\n",d_in0);
Quote:
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.

Y.V.V.Nagendra
Guest

Mon Aug 13, 2018 6:45 pm   



On Monday, August 13, 2018 at 2:47:42 AM UTC+5:30, Gabor wrote:
Quote:
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);
Quote:
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.

Robert Willy
Guest

Thu Aug 16, 2018 2:45 pm   



On Monday, August 13, 2018 at 11:49:35 AM UTC-5, Y.V.V.Nagendra wrote:
Quote:
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.

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.

elektroda.net NewsGroups Forum Index - Verilog Language - Why are these two signals the same waveform?

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map