Latches are generated for the "assigned to" signals.
You could define these, as Dave Tweed said, as output signals.
Latches appear if you have combinatorial logic where a variable does not get assigned a value in every possible path.
You find latches by checking every if, else, case, when etc. to see if at that point in the code a value has been ...
For some reason, if i sets the control range to 0 to 10, it works, but I can't explain why, it's like before a length overflow occurred in buff signal.
It can be demonstrated with a a simple testbench:
entity paralelsequencial_tb is
architecture foo of paralelsequencial_tb is
signal clk: ...
I'd never let this pass through code review, but not because you want to write a lookup table. Combinatorial logic definition using signals was relevant in the 1980s, but we're 4 decades later now.
The whole concatenation/lookup really belongs in a process, like so:
p_main: process(a, b, c)
variable together : std_logic_vector(2 downto 0);
Your ports are of "std_logic_vector" type but the internal signal Out5bit is unsigned.
Numeric_std doesn't provide an "+" operator that adds the first type and returns the other, so no matching "+" operator is visible.
Three approaches to fix this:
1) Type conversions from std_logic_vector to unsigned and back again. Ugly, but clearly describes what you ...
The best you can do is to use the high period from the clock to 'gate' a compare signal. But you might still end up with some 'runt' pulses. This is what might get:
This is where the 'runt' pulses can come from:
At the beginning your individual dat1 bits will have tiny delays to get to the final value. Thus your compare might not straight go to 1 or 0 ...
Why aren't these 3 ways of doing this the same in this case?
The behaviour of the three codes is NOT identical.
R <= R + 1 when (rising_edge(clk)) else
"00000000" when (rising_edge(btn_center)) else
R has to change on a rising clock edge, but if there is no rising clock edge it has to reset on a rising btn_center edge.