variable in a loop

[Matthias Alles]

Hi!

I have a question regarding the following process, which doesn't what I
expected:

process(input_reg) is
variable interm: std_logic_vector(10 downto 0);
begin
for i in 0 to 10 loop
interm(i) := input_reg(31-i);
result <= unsigned(interm);
end loop;
end process;

where input_reg is std_logic_vector(0 to 31) and result is unsigned(10
downto 0)

In the simulation result will be set to "0UUUUUUUUUU". What I expected
was "0000000000" when the input reg is all-zero. Why are the bits all
undefined except for the bit that is set in the very last loop
iteration? Shouldn't each loop iteration set one additional bit, such
that in the last iteration all bits are set?
When I move the "result <= unsigned(interm);" outside of the loop the
thing simulates as expected.

Could anyone explain this to me?

Matthias

 

[KJ]

Hi!

I have a question regarding the following process, which doesn't what I
expected:

process(input_reg) is
  variable interm: std_logic_vector(10 downto 0);
begin
  for i in 0 to 10 loop
     interm(i) := input_reg(31-i);
     result <= unsigned(interm);
  end loop;
end process;

where input_reg is std_logic_vector(0 to 31) and result is unsigned(10
downto 0)

In the simulation result will be set to "0UUUUUUUUUU". What I expected
was "0000000000" when the input reg is all-zero. Why are the bits all
undefined except for the bit that is set in the very last loop
iteration?

Because you assign every bit of 'result' on every iteration of the
loop with your statement result <= unsigned(interm);

Shouldn't each loop iteration set one additional bit, such
that in the last iteration all bits are set?

It would if you had selected only those particular bits of result
(i.e. result(i) or something) in your assignment.

When I move the "result <= unsigned(interm);" outside of the loop the
thing simulates as expected.

That makes one single assignment of result rather than one for each
time through the loop. Remember signal assignments are different than
variable assignments, the signals don't get updated until the process
suspends either explicitly via a wait statement or implicitly by
getting to the end of the process.

Kevin Jennings

 

[Matthias Alles]

It would if you had selected only those particular bits of result
(i.e. result(i) or something) in your assignment.

But why doesn't this hold for the variable? I update one single bit in
the variable per loop iteration. In the last loop iteration all bits of
the variable are set. So I just don't understand why it makes a
difference when I move the signal assignment into the loop or not, since
in the last iteration all bits of interm should be set to proper values.

That makes one single assignment of result rather than one for each
time through the loop. Remember signal assignments are different than
variable assignments, the signals don't get updated until the process
suspends either explicitly via a wait statement or implicitly by
getting to the end of the process.

I know ;-) So my last assignment of result is the one that is done in
the last loop iteration (where all bits of the variable should have been
set).

Matthias

 

[KJ]

But why doesn't this hold for the variable? I update one single bit in
the variable per loop iteration. In the last loop iteration all bits of
the variable are set. So I just don't understand why it makes a
difference when I move the signal assignment into the loop or not, since
in the last iteration all bits of interm should be set to proper values.

I think I misinterpreted what you were saying earlier. In any case,
it doesn't make a difference where you put the assignment of result,
copied below is the code I simulated and 'result' ends up as
"00000000000" at t=0ns, Delta=1.

If you're getting something else than there is likely more to your
simulation model than you've described and that 'something
else' (maybe some other process) also outputs 'result'.

-- Start of code
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity foo is
end foo;

architecture rtl of foo is
signal input_reg: std_logic_vector(31 downto 0) := (others =>
'0');
signal result: unsigned(10 downto 0);
begin
process(input_reg) is
variable interm: std_logic_vector(10 downto 0);
begin
for i in 0 to 10 loop
interm(i) := input_reg(31-i);
result <= unsigned(interm);
end loop;
end process;
end rtl;
-- End of code

Kevin Jennings

 

[Mike Treseler]

I have a question regarding the following process, which doesn't what I
expected:

process(input_reg) is
variable interm: std_logic_vector(10 downto 0);
begin
for i in 0 to 10 loop
interm(i) := input_reg(31-i);
result <= unsigned(interm);
end loop;
end process;

where input_reg is std_logic_vector(0 to 31) and result is unsigned(10
downto 0)

In the simulation result will be set to "0UUUUUUUUUU". What I expected
was "0000000000" when the input reg is all-zero.

Maybe the testbench does not
move a zero to input_reg
before the process starts.



My problem with debugging code snippets like this
is that there is no clear input or output to
make to make the logic easy to simulate.

In this case I would first take the value formation
part of this problem *out of time*
by writing a function like this:

function reverse (constant arg : unsigned)
return unsigned is
variable rev_v : unsigned(arg'reverse_range);
begin
for i in arg'range loop
rev_v(i) := arg(i);
end loop;
return rev_v;
end function;


and testing it like this:

assert reverse("1011011101111") = "1111011101101"
report "error in function reverse";


-- Mike Treseler

 

[Jeff Cunningham]

Maybe the testbench does not
move a zero to input_reg
before the process starts.

Don't see how this could be the case since he said if the result <=
unsigned(interm) statement is moved outside the loop it works.

-Jeff

 

[Mike Treseler]

Don't see how this could be the case since he said if the result <=
unsigned(interm) statement is moved outside the loop it works.

Neither KJ or I were able to reproduce this result.
Something is wrong with the testbench.

-- Mike Treseler

 

[Thomas Stanka]

I know ;-) So my last assignment of result is the one that is done in
the last loop iteration (where all bits of the variable should have been
set).

Mybe you should write which simulator you are using. I guess the
simulator did some error in loop unroling or mixed up some signal
assignments (if there is no other code construct responsible for the
observed behavior).
Why do you use such error-prone code anyway?

regards Thomas