while condition

D

Daniel

Guest
I am learning VHDL.

I have a doubt with an entity.

My entity have : 2 input and 1 output.

entity despIzq is
Port ( entrada : in std_logic_vector(4 downto 0);
despl : in std_logic_vector(4 downto 0);
salida : inout std_logic_vector(4 downto 0));
end despIzq;

Their behavior is:

salida = entrada sll despl

for example:

entrada <= "00010";
despl <= "00010";

salida => "01000"

my code is:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

-- Uncomment the following lines to use the declarations that are
-- provided for instantiating Xilinx primitive components.
--library UNISIM;
--use UNISIM.VComponents.all;

entity despIzq is
Port ( entrada : in std_logic_vector(4 downto 0);
despl : in std_logic_vector(4 downto 0);
salida : inout std_logic_vector(4 downto 0));
end despIzq;

architecture Behavioral of despIzq is

signal tmp : std_logic_vector (4 downto 0);
signal tmp_2 : std_logic_vector (9 downto 0);
signal tmp_3 : std_logic;
constant ZERO: std_logic_vector (4 downto 0):="00000";

begin
process(entrada,despl)
begin
tmp <= despl;
tmp_2<="0000000000";
while tmp > ZERO loop
tmp_3 <='1';
tmp_2 <= salida * "00010";
salida <= tmp_2(4 downto 0);
tmp<=tmp-1;
end loop;
end process;
end Behavioral;

tmp_3 is to see if the condition of the "while" is true.

the problem is that it never enters in loop statements.

tmp_3 never is 1

Somebody can help me, please!!!

Thank you very much.
 
Daniel wrote:

O.k., let's have a look at a part of your process:

process(entrada,despl)
begin
tmp <= despl;
....
while tmp > ZERO loop
....
tmp<=tmp-1;
end loop;
end process;
Click to expand...
The process is executed, if one of the signals out of the sensitivity
list change.
Then tmp gets a value assigned (in the next delta delay).
Then the /old/ value of tmp is tested, if bigger than ZERO. (The new
value is assigned in the next delta delay!) If it is true, the
while-body is executed.
And whats happening in the while-loop? You assign another new value to
tmp (in the next delta delay). The old value assigned outside the loop
is overwritten. Then the loop ends and the condition is evaluated again.
But this is done in the /same simulation step/ - not in the next delta
delay. Therefore tmp carries it's old value! And therefore it is an
infinite loop.

If you would make tmp a variable, it would be updated immediately - not
in the next delta cylce like the assignment to a signal. Therefore the
loop may terminate sometimes. But nevertheless the loop is executed in
one simulation step and this means zero time.

O.k., you might say, a varibale tmp is only a counter for the while
condition (although a for-loop may preferrable for this), but let's have
a look at a /modified/ version of your process:

process(entrada,despl)
variable tmp : unsigned(4 downto 0);
begin
tmp := despl;
tmp_2<="0000000000";
while tmp > ZERO loop
tmp_3 <='1';
tmp_2 <= salida * "00010";
salida <= tmp_2(4 downto 0);
tmp:=tmp-1;
end loop;
end process;

What would happen? tmp_2 gets a new value (the /old/ salida * "00010")
and then salida gets a new value (the /old/ value of (tmp_2(4 downto
0)). This happens again and again until the while-loop terminates.
Finally the loop is completely useless. (This holds especially for tmp_3.)


So ask yourself: What you are trying to model with this code? It seems
to be, that you are writing software and think, that everything es
executed step-by-step like in a software language.

I'm not shure whats your intention whith this code and therefore I can
give you only one hint: Think hardware! For this you have 3 elements:

1) filpflop:

process(reset,clock)
begin
if (reset = '1') then
-- do some async reset
elsif rising_edge(clock) then
-- do your stuff
end if;
end process;


2) latch

process(enable,data)
begin
if (enable = '1') then
latch_signal<=data;
end if;
end process;


3) combinational logic

process(selector1, selector2,data)
begin
if (selector1 = '1') then
comb_signal<=data;
elsif (selector2 = '1') then
comb_signal<='0';
else comb_signal<= NOT(data);
end if;
end process;

You really don't need more to describe a lot of circuits. I sugest to
think about your problem using flipflops. Make it synchronous and
everytime a clock-edge arrives, then do some computation.

And at last: Loops in VHDL a mostly used to reduce the amount of code.
They are (mostly) not used to model something sequential like in a
software language. For this we have state machines in VHDL (and also in
software languages).

Example for a for-loop in VHDL:

signal wide : std_ulogic_vector(15 downto 0);
signal narrow : std_ulogic_vector(7 downto 0);

process(wide)
begin
for N in 0 to 7 loop
narrow(N)<=wide(N*2); -- select every 2nd bit
end loop;
end process;

I could also write

narrow(0)<=wide(0);
narrow(1)<=wide(2);
narrow(2)<=wide(4);
....
narrow(7)<=wide(14);

but obviosly its easier to take a loop. Therefore the loop is nothing
more than a handy description in this example.

Ralf
 
Thank you per your explanation.

My problem is that I am trying to translate a program written in C to VHDL.

When I program, think in software programing not hardware programing.


Thanks.
 
Daniel wrote:

My problem is that I am trying to translate a program written in C to VHDL.
Click to expand...
Whats your intention? Writing just a testbench and using a common
software algorithm or a real synthesizable software to hardware mapping?


When I program, think in software programing not hardware programing.
Click to expand...
If you want to write synthesizable code, you should (almost) forget the
software stuff.
Coding a software is writing step-by-step instructions. Describing
hardware is connecting hardware elements - or at a higher level of
abstraction - using something like a state machine to get a step-by-step
behavior.


Ralf
 
My intention is a real synthesizable software to hardware mapping.

I am programming with Xilinx.

The intention is to translate the code, written in C, to VHDL and
synthesizable in a XSA-200 board of Xilinx.
 
Daniel wrote:

My intention is a real synthesizable software to hardware mapping.

I am programming with Xilinx.
^^^^^^^^^^^
Click to expand...
As Neo already said: Don't program hardware! Model it!
And additionally: Good code runs on (almost) every target - so at first
forget that you are using a Xilinx FPGA and just code VHDL.


The intention is to translate the code, written in C, to VHDL and
synthesizable in a XSA-200 board of Xilinx.
Click to expand...
Almost everytime there is NO "translation" from any software language to
a HDL. You have to find a mapping of the algorithm to the hardware.
What's the difference? "Translation" implies simple substitution of
keywords and similar language constructs. Mapping an algorithm is
finding a suitable hardware for the idea stated in the mentioned algorithm.

Try to find a _data path_ for your algorithm: You need some busses, some
execution units (adders, multipliers...), some muxes and a machine that
controls the data path (a state machine.)


And again - to show you, that this is not that complex, as it may seem:
You only need 3 hardware types: flipflops, latches and combinatorical
logic. (And additionally: I would recommend to avoid latches for a
beginner.) This means you only need storage elements and some
combinatorcial gates. Try to find a way to map the algorithm to these
elements.

I strongly recommend to read a chapter in a HDL book about state
machines. There you will see, how step-by-step "instructions" are modelled.

Ralf
 
might try:
while tmp /= ZERO loop

But you might need to reconsider your code, because 'signal' types do
not update instantaneously, the process needs to exit first.

I'm not exactly sure what you're trying to do, but you might want to
consider making the assignment

tmp <= despl;

outside the process -- of course if you are doing other stuff with that
signal you may need a different solutions.
 
<quote>
When I program, think in software programing not hardware programing.
</quote>
oh baby, You first need to bridge the gap and start thinking in terms
how hardware is realised in physical reality. Until then code and pray.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top