# 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?

initial
begin
repeat(10) @(posedge clk);
rst <= 1'b1;
@(posedge clk);
rst <= 1'b0;
repeat(5) @(posedge clk);
while (!\$feof(x_in))
begin
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?

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

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?

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

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:
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?

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

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:
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?

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

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:
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?