Clock Edge notation

[info_]

Hi Mike,

Mike Treseler wrote:

"if then else elsif elsif ... "
only implies priority if cases overlap.

if A(7) = '1' then Q <= "111";
elsif A(6) = '1' then Q <= "110";
etc...
do overlap, but even then, it does not necessarily
require or imply a priority-based implementation.

I agree that std_ulogic_vector is usually
more trouble than it's worth.
However std_ulogic has no such downside.
I use std_ulogic as my default bit type.
It port maps directly to std_logic without conversion.

Seems I was a bit too quick to burry std_ulogic...

I still won't use it, nor RTL procedures, but this is more
a matter of habits and personal taste. I once suspected that
you were using both as a hidden signature to copyright your code
;-)

Cheers,

Bert Cuzeau

 

[Mike Treseler]

Hi Bert,

info_ wrote:

if A(7) = '1' then Q <= "111";
elsif A(6) = '1' then Q <= "110";
etc...
do overlap, but even then, it does not necessarily
require or imply a priority-based implementation.

I agree. Synthesis is free to make
any netlist that sims like the code.
I have found that coding style has a
negligible effect on utilization
for equivalent descriptions.

My point was that the logical idea
of priority does not apply to all
problems. Some are pieces of pie
and some are Olympic rings.

I still won't use it, nor RTL procedures, but this is more
a matter of habits and personal taste. I once suspected that
you were using both as a hidden signature to copyright your code
;-)

Yes. It's a little like changing the
spelling of my name on magazine
subscriptions to see where it goes.

Cheers

Hey howdy,

-- Mike Treseler

 

[info_]

I need to add some more information to be absolutely accurate :

-- -------------------------------------
Architecture RTL_if of HOTDECOD is
-- -------------------------------------
-- and how many LUTS for this one ?
-- Isn't this description easier to rewrite under
-- the form of a (size-independant) function ?
begin

process (A)
begin
if A(7) = '1' then Q <= "111";
elsif A(6) = '1' then Q <= "110";
elsif A(5) = '1' then Q <= "101";
elsif A(4) = '1' then Q <= "100";
elsif A(3) = '1' then Q <= "011";
elsif A(2) = '1' then Q <= "010";
elsif A(1) = '1' then Q <= "001";
elsif A(0) = '1' then Q <= "000";
else Q <= "---"; -- don't care
end if;
end process;
-- do you see a "priority" in the synthesized result ???

There IS in fact a priority in the description above which is
indeed respected in the synthesized result ! This description
works as a one hot decoder, but it is also a priority encoder
when it handles the overlapping cases.
This is why this solution is still not optimal (as a one-hot decoder)!
(5 LUTs instead of 3).

A really optimized one hot decoder (with all synthesis tools) can
be built with the following function (provided by S. Weir in an
old post) :

----------------------------------------------------------------------------
-- Encode a vector of discrete bits into a binary vector representation,
-- WITHOUT guarding against multiple bits on.
--
-- For a single bit on, the encoded value is the offset from the
-- low index of src of the asserting bit, regardless of src's
-- endianness.
----------------------------------------------------------------------------
function fnEncBin ( src : std_logic_vector ) return std_logic_vector is
variable rslt : std_logic_vector( fnLog2M( src'length ) - 1 downto 0 ) ;
begin
rslt := ( rslt'range => '0' ) ;
for rslt_idx in rslt'range loop
for src_idx in src'length - 1 downto 0 loop
if( ( ( src_idx / ( 2**rslt_idx ) ) MOD 2 ) = 1 ) then
rslt( rslt_idx ) := rslt( rslt_idx ) OR src( src_idx + src'low ) ;
end if ;
end loop ;
end loop ;
return( rslt ) ;
end ;

This function simply infers the OR gates directly !
In the case of this post, the one hot decoder ends up in
three (4 inputs) LUTs, one logic layer instead of 2 (or more).
I don't think there is any other description that infers the
minimal result with all synthesis tools.

Bert Cuzeau

 

[John_H]

"Bryan" <bryan@srccomp.com> wrote in message
news:1114802127.737459.181520@l41g2000cwc.googlegroups.com...

Stop by any time you like and sign an NDA, I think you can figure out
where I am. I will be happy to show you my async FIFO schematic and
why it integrates with higher performance than a coregen type FIFO. I
don't design in VHDL or verilog because I am not a wizard, just an
average engineer.

Average engineers aren't pompous.
Do you even KNOW where the first real async FIFOs came from?

 

[info_]

Just a few extra comments :

Mohammed A khader wrote:

All say that case infers a parallel logic and if-elsif-else infers
a proirity encoder structure ...

They don't quite say this (or they'd lie).
"If ... elseif" has an implied priority (first test true -> next tests
are not taken)... but that makes no sense when you describe a truth table !
(as in my first encoder example)
Whatever the means to describe behaviorally the truth table, it
will end up the same, and by way of logic reduction it will lead
to implementations that may or may not be similar depending
on synthesis tools optimization goals, constraints, internal
logic reduction algorithm, etc...
Things may become different when complex operators are inferred.
The BIG difference is that, from a synthesis perspective,
describing a truth table isn't the same as describing higher
level structures !

What I mean is be wary of general rules about synthesis. There are more
than one tool, and tens of years of research behind them...
I think it's pretty dangerous to say "this does infer that".
Or you have to be damn accurate : given code snippet, given tool,
given version, given technology, given constraints, etc etc

problem of qulifying expression has been addressed by vhdl committee
and it is going be fixed soon.

1. I didn't mean it was a problem ! You just need to know the language.
Qualified expressions are just often unknown to newbies, but they
are extremely useful. write (L,"hello"); for example.
There's no problem in writing "case A&B" (a qualified expr does it).
It's also possible to get directly the two MSBs of A + B (vectors).
One just needs to know a bit more than the basics of VHDL.

2. What do you mean by "has been addressed..."? I don't want to start
another controversy, but VHDL200X isn't out of the woods.
We all just hope it will happen (out of IEEE and then into our tools)
before the EDA community majority has switched to SystemVerilog.
But there is absolutely no real need of a better VHDL for simple designs.

completness of case is an advantage to find the bugs.Lets take an
example....

It's MUCH easier to follow good coding rules which ensure that the
bad situation you mention will never happen in your design that
trying to test every signal again 'U' !
If you want to do this, be consistent and write a test for every
numeric vector, making sure it doesn't include any 'U'. Not cool.

Simple gross mistakes are easier to prevent than to detect.

I think this is the same with std_ulogic, which use was supposed
to help detect multiple drivers situations (it did). But there
are other ways to check this and so many other bad things are
to be tested at synthesis that everybody has dropped now this
unresolved type and obsolete style.

I dont know partiuclarly about one hot minimal decoder but
Synthesis tools say case statments are good for area opptimizations.

It's called hearsay I think.
Then, why doesn't it show up in the simple examples I gave ?
(XST 6.3.03i creates in fact a larger design with the "case" version)

I have reproduced below an old example that I sometimes used
in my courses. I kept it simple minded (no fancy function).
Why don't all synthesis tools give the simple OR gates ?
- The case version "looks" nicer, but check the gates count (with your tool).
- In the "if" solution : do you see a priority after synthesis ??
Chances are your synthesis tool will produce three times larger solution
with the case than with the if.
Don't believe ppt slides (nor me) !

Dont under estimate the number of gates as it is know
causing more static power.

0. How do you know you have "saved" some gates and achieved
and an optimal solution ? What do you compare against ?
In the example below, was 15 LUTs acceptable or not ? (without
the comments saying it was not).

1. The case doesn't always produce less gates, sometimes
the contrary as proved here.
I try to not underestimate anything ! I just check by myself
as much as I can and I encourage you, if you're sensitive to gate
count and QOR, to always verify and never simply "assume".

2. If design could be made significantly smaller by avoiding "ifs",
then don't you think the Synthesis tools would automatically do
the translation internally ? (they do, this and many other tricks)

3. There is one or two orders of magnitude higher potential gain
by smart implementation and good design know-how :
being a smart architect pays !

4. Most synthesis tools are smarter and smarter, so a good
understanding of your specific tool is also a good investment.

5. FPGAs and ASICs are two different worlds. What applies to one not
necessarily applies to the other. Synthesizing to LUTs and to GATEs
isn't the same. Don't forget Synopsys is an ASIC company.
Driving DC ins't the same as doing FPGA synthesis.

6. Significant Power consumption reduction requires other techniques
than using case instead of if (supposing that there is any gain
at all doing so).

7. Gate count is definitely less and less an issue, even in the
ASIC field ! Challenges have moved, and old books don't reflect this.

My experience is : Synthesis tools are often smarter than the designer
thinks, but there are also sometimes doing some apparently "stupid"
things (at least looking like such for unexperienced designers).
Just try Q <= A + B - A - B; -- unsigned vectors.

And please do *NOT* avoid the case statement when it is appropriate !!!

Again, HDL code should be as simple, clear and expressive as possible,
easy to understand and maintain, and not error-prone. I assign a higher
priority to these criteria in our designs.

After a good ground learning, learn by trying. This is fun anyway.
You must end up "thinking" like your synthesizer, then you'll be
real efficient.

Bert Cuzeau
"Let's save the poor IF from damnation !" Commitee
12, Gate(s) Lane
Mux Island

(donations accepted, FFs* and LUTs only)
* FlipFlops, not French Francs


----------------------------
-- HOTDECOD.VHD
-- -------------------------------------
-- One-Hot Decoder
-- -------------------------------------
-- ALSE. http://www.alse-fr.com/english
-- This design must be synthesized as 3 x OR gates (4-inputs)
-- Any extra logic is unnecessary.
--

library IEEE;
use IEEE.std_logic_1164.all;

-- -------------------------------------
Entity HOTDECOD is
-- -------------------------------------
port ( A : in std_logic_vector(0 to 7);
Q : out std_logic_vector(2 downto 0)
);
end;

-- -------------------------------------
Architecture RTL_case of HOTDECOD is
-- -------------------------------------
-- check how many LUTS for this one...
-- How do you code this as a generic size decoder ?
begin

process (A)
begin
case A is
when "00000001" => Q <= "111";
when "00000010" => Q <= "110";
when "00000100" => Q <= "101";
when "00001000" => Q <= "100";
when "00010000" => Q <= "011";
when "00100000" => Q <= "010";
when "01000000" => Q <= "001";
when "10000000" => Q <= "000";
when others => Q <= "---"; -- don't care
end case;
end process;
-- Note : the "case" above is auto-full and auto-parallel in Verilog sense.
-- Quite obviously, one solution is :
-- Q2 = A0 or A1 or A2 or A3
-- Q1 = A2 or A3 or A6 or A7
-- Q0 = A1 or A3 or A5 or A7

end RTL_case;

-- -------------------------------------
Architecture RTL_if of HOTDECOD is
-- -------------------------------------
-- and how many LUTS for this one ?
-- Isn't this description easier to rewrite under
-- the form of a (size-independant) function ?
begin

process (A)
begin
if A(7) = '1' then Q <= "111";
elsif A(6) = '1' then Q <= "110";
elsif A(5) = '1' then Q <= "101";
elsif A(4) = '1' then Q <= "100";
elsif A(3) = '1' then Q <= "011";
elsif A(2) = '1' then Q <= "010";
elsif A(1) = '1' then Q <= "001";
elsif A(0) = '1' then Q <= "000";
else Q <= "---"; -- don't care
end if;
end process;
-- do you see a "priority" in the synthesized result ???


end RTL_if;

 

[backhus]

Hi Symon,
for (most) of the given examples case and if-elsif will give the same result.
Why?
Because in both cases your selector is fully covered (uses all of the bits of a vector or whatever you use as a
selector). Your if-elsif collapses into a parallel structure, because there is no priority of one value over the other
possible.

but how about this:

Selector <= A&B&C; -- I MUST do this for a case statement !
case Selector is
when "001" => Output <= Input1;
when "010" => Output <= Input2;
when "100" => Output <= Input2;
when others => Output <= (others => 'Z');
end case;

vs.

If C = '1' then
Output <= Input1;
elsif B= '1' then
Output <= Input2;
elsif C= '1' then
Output <= Input3;
else
Output <= (others => 'Z');
end if;

NOW the case produces a parallel multiplexer structure that is sensitive for the given code of Selector.
The if-elsif does something different. Whenever C becomes '1' (No matter how unlikely or unneccesary this might be in
your particular design) it switches Input1 to the output. Here we have the always cited priority encoder.

To get the same functionality with a case you have to write a different code:

Selector <= A&B&C; -- I MUST do this for a case statement !
case Selector is
when "--1" => Output <= Input1;
when "-10" => Output <= Input2;
when "100" => Output <= Input2;
when others => Output <= (others => 'Z');
end case;

Now the first >when< hits whenever C becomes '1'.
This code might produce something more "parallel" than the if-elsif, but who knows about the tricks of modern synthesis
tools.

Have a nice synthesis

Eilert

 

[Laurent Gauch]

Bernasconi Sacha wrote:

Sto creando un sito sul vhdl in italiano, contenente una guida di
base, collegamenti a guide avanzate e un forum di discussione.
Se a qualcuno puň interessare e avesse voglia di iniziare a far vivere
il forum questo č l'indirizzo: http://vhdl.onlinedreams.ch
Saluti

You could add our VHDL Memo to your links.
Link is http://www.amontec.com/fix/vhdl_memo/index.html

Saluti
Larry
------------ And now a word from our sponsor ------------------
Want to have instant messaging, and chat rooms, and discussion
groups for your local users or business, you need dbabble!
-- See http://netwinsite.com/sponsor/sponsor_dbabble.htm ----

 

[backhus]

Hi Dan,
first thing to do: Think of the hardware you want to create.

A device with 12 output lines always ever has these wires.
There is no magical monkey inside the chip, riping off unused wires and reconnecting them as needed.
It's HARD-ware!

But then...
If you want to transmit the data, you can do it in some serialized manner.
With the help uf some useful algorithm
or even a simple dataformat (e.g. Datalength(4bits), Data (0 to 12 bits variable)).
(well, an dataformatter also has some kind of algorithm inside..)

In the end you see that compression only works by serialisation.
Otherwise you always have to keep your wires with you all the way.

Have a nice synthesis
eilert


Dan Nilsen schrieb:

Hi all!

I have a problem that someone here might have the answer to. I have a
divider that takes inputs of 13 and 12 bits, and produces an output of
12 bits. I have a component to strip away the redundant bits from the
divider, if the result of the division is, say an int value of 6, I
don't want to use all 12 bits. This circuit is a part of an MPEG-4
device, a quantizer, so I want to compress as much as possible. My
question is then, how do I declare the ports on the component that
strips away the bits to output an std_logic_vector that is not fixed
in size, but dynamic? This must be synthesizable. Guess there are many
ways of doing this, and I hope someone has got an answer to me.

Thanks,

Dan Nilsen

 

[Ralf Hildebrandt]

Simon.Tiplady@gmail.com wrote:

In the following code what does >> represent?

Shift right. 2nd operand is the number of bits to shift.

Ralf

 

[Ralf Hildebrandt]

Pasacco wrote:

-----------------------------------------------------------------
Fatal: (vsim-7) Failed to open VHDL file "text.txt" in r mode.
# No such file or directory. (errno = ENOENT)
-----------------------------------------------------------------

Specify the complete path for the file - not only it's name.

e.g.:
file AAA : TEXT open READ_MODE is "/home/userX/folderY/text.txt";


Ralf

 

[Alan Peter Fitch]

Taras_96 wrote:

Ok, can anyone tell me why:

constant B4 : unsigned := "010";
constant CONST : unsigned := B4 + "001"; --is NOT locally static

constant B4 : integer := 2;
constant CONST : integer := B4 + 1; -- is locally static

Taras

I seem to remember that the process of slicing a vector is considered
non-static, so perhaps the creation of the anonymous subtype of the
unsigned vector makes it non-static. I shall look it up in the standard
when at work.

In the case of the integer, there is no anonymous subtype created as no
subtype of integer if implied.

In the case of unsigned, the vector will deduce its width from the size
of B4.

regards
Alan

--
Alan Fitch (at home)
reverse: org dot ieee dot apfitch

 

[Alan]

In message <3dn974F6rs3imU1@individual.net>, Ralf Hildebrandt
<Ralf-Hildebrandt@gmx.de> wrote

Pasacco wrote:


-----------------------------------------------------------------
Fatal: (vsim-7) Failed to open VHDL file "text.txt" in r mode.
# No such file or directory. (errno = ENOENT)
-----------------------------------------------------------------

Specify the complete path for the file - not only it's name.

e.g.:
file AAA : TEXT open READ_MODE is "/home/userX/folderY/text.txt";

Some tools don't like white spaces in the names of files or directory
paths. It is better to always use names like 'my_directory' with an
underscore rather than 'my directory' with a space in the name.

--
Alan
mailto:news2me_a_2003@amacleod.clara.co.uk

 

[Duane Clark]

Taras_96 wrote:

Ok, can anyone tell me why:

constant B4 : unsigned := "010";
constant CONST : unsigned := B4 + "001"; --is NOT locally static

I think because CONST is an unconstrained array. Try
constant CONST : unsigned(2 downto 0) := B4 + "001";
or some such.

constant B4 : integer := 2;
constant CONST : integer := B4 + 1; -- is locally static

Taras

 

[info_]

Neo wrote:

Info,
The code above given by you for onehot did sysnthesize differently. the
"case" version systhesized to 3 LUT's involving only OR gates and didnt
infer priority structure infact it optimized as you have mentioned to a
series of OR gates. But the "if" version systhesiszed to 6 LUT's and
inferred a priority structure. Leonardo was used for the systhesis.

Yes my point exactly. Not all tools do this correctly. Leoanrdo is right.

Just try Precision Synthesis (or other tools) if you can and compare
the results.

The if .. elsif is a priority encoder which has a well defined behavior
for the overlapping cases (more than one 1 in the vector), and this
requires more logic than the "pure one hot". This edscription is
more predictible acroos tools.


Bert

 

[info_]

backhus wrote:

Hi Symon,
for (most) of the given examples case and if-elsif will give the same
result.
Why?
Because in both cases your selector is fully covered (uses all of
the bits of a vector or whatever you use as a selector). Your if-elsif
collapses into a parallel structure, because there is no priority of one
value over the other possible.

but how about this:

Selector <= A&B&C; -- I MUST do this for a case statement !
case Selector is
when "001" => Output <= Input1;
when "010" => Output <= Input2;
when "100" => Output <= Input2;
when others => Output <= (others => 'Z');
end case;

vs.

If C = '1' then
Output <= Input1;
elsif B= '1' then
Output <= Input2;
elsif C= '1' then
Output <= Input3;
else
Output <= (others => 'Z');
end if;

NOW the case produces a parallel multiplexer structure that is sensitive
for the given code of Selector.
The if-elsif does something different. Whenever C becomes '1' (No matter
how unlikely or unneccesary this might be in your particular design) it
switches Input1 to the output. Here we have the always cited priority
encoder.

To get the same functionality with a case you have to write a different
code:

Selector <= A&B&C; -- I MUST do this for a case statement !
case Selector is
when "--1" => Output <= Input1;
when "-10" => Output <= Input2;
when "100" => Output <= Input2;
when others => Output <= (others => 'Z');
end case;

Now the first >when< hits whenever C becomes '1'.
This code might produce something more "parallel" than the if-elsif, but
who knows about the tricks of modern synthesis tools.

Have a nice synthesis

Eilert

Just a few errors :

1. you can in fact qualify the expression and not use a signal.
A variable is usually preferable if you want one (otherwise,
you must add Selector in your sensitivity list, and this slows down
the simulation without usefulness).

case SLV3'(A&B&C) is -- with subtype SLV3 is std_logic_vector (3 downto 0);

2.
output <= 'Z' infers a tristate, nothing to do with a don't care!
A don't care '-' does eliminate C from the result.

3. case ... is when "--1" is wrong !
Comparing anything (but a '-') to '-' produces a false.
Comparing with '-' (to ignore the comparison) requires the use
of std_match (not usable in case statement).


VHDL is not always intuitive...


Bert Cuzeau

 

[info_]

shgjoker@gmx.de wrote:

Hi guys,

a wrote a gouple of days ago a question about the cf_fft from
opencores.org.
Anyway i want to thank Bert because he helped me( my mistake wasthat i
made a error by changig the design from numeric package to arith
package.
Now the system is running, but as i said before its "only" a part of
the overall system and i got no time from my supervisor to design my
own fft ( i wish i had).
My problem is that i need to know the value of each single bit at the
in oroutput(sign 2^?), i tried it with sinewaves( to find real and im
parts of the frequency
bins),i tried also some dc values because i thought their would be a
zero frequency bin. Farther i tried noise and combinations of those
signals, but i was not able to find the specific characters of each
signal.
I think it's only a trivial thing that i don't see, but it's not my
design and it's designed with a generation tool (8000 lines)whitch
makes it impossible to read the code.

Greetings Marco

You should try to get all the documentation you can about this
generated fft. I don't have a very good impression, and my simulation
results are a bit weird too (but I see the input noise and some high
bins when I inject noise + Sinewave), so I guess the data_in has another
format than the one I tried (tried I on data_0 and Q on data_1), and
it may also not support a continuous flow. But I havent reead the
documentation, so it's ont very serious.
Since the VHDL "source" is not much more than a netlist (probably as useless),
I would see this as another incentive to abandonning it and using a
vendor's macro. These macros are now quite good, well documented, and
very efficient.
If you dont have much time and want an efficient FFT in your project,
using the vendor's macro might well be the way to go....
This or rewriting your own radix-based FFT.

Bert Cuzeau

 

[dade]

cito dal tuo sito:

Tradotto in italiano quindi VHDL sta per: linguaggio di descrizione
hardware per circuiti a velocitŕ d'integrazione molto alta.

non sarebbe
linguaggio di descrizione hardware per circuiti integrati ad alta velocitŕ.

Scusa la pignoleria, ma se mi cadi proprio sulla definizione

Comunque per l'universitŕ devo imparare anche io il vhdl, quindi terrň
il tuo sito come risorsa utile!
Grazie quindi... aspettati contributi!

Davide

http:\\omegalab.altervista.org

 

[Ronald H. Nicholson Jr.]

In article <1114556692.455174.18400@f14g2000cwb.googlegroups.com>,
Peter Alfke <peter@xilinx.com> wrote:

Berty, I disagree.
While it is good for every young engineer to learn the basic skills,
designing an asynchronous FIFO is far from "basic".

I realize your credentials, but I will still have to disagree.

Asynchronous boundary crossings are even more common these days than
in previous decades (systems supporting a plethora or protocols and
standards, chips so big and fast that signals can't even cross it in one
clock cycle, etc.), and dealing with clock domain crossings needs to be
part of the basic toolkit of almost any competent digital design engineer.
If a system requires an async FIFO, there is a reasonable probability
that there are other async crossings involved. An engineer who doesn't
understand the basic problem and solution space will possibly screw-up
somewhere other than the FIFO, especially if he/she doesn't even have
a basic understanding of even how to solve and not solve the problem
using at least some form of simplified logic structures.

Now if you want to do analog circuit design of full-custom ASIC flip-flops
to tweak the the metastability window a few picoseconds smaller at the
same statistical certainty level, I'll agree that that may no longer be
a basic skill.


IMHO. YMMV.
--
Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/
#include <canonical.disclaimer> // only my own opinions, etc.

 

[Ronald H. Nicholson Jr.]

In article <1114818211.545915.148920@o13g2000cwo.googlegroups.com>,
Peter Alfke <peter@xilinx.com> wrote:

But back to simulation:
I have tested metastability in our flip-flops, and I found that the
metastability-catching timing window has a width of
0.07 ns for a metastable-caused delay of 1 ns
0.07 femtoseconds for a metastable-caused delay of 1.5 ns.
For every extra half ns of delay, the window becomes a million times
smaller.
For a 2-ns delay you have to hit a timing bulls-eye of 10e-22 seconds.
Please tell me how you can simulate that...

One engineering rule is that "there is no such thing a digital". You
seem to understand that. Digital logic is just a simplification of analog
electronics used well away from thresholds. But another, more subtile
rule is that "there is no such thing as analog". At 10e-22 seconds
you are closer to the limits of electrical and thermal noise, maybe
even quantum uncertainty. Neither standard Spice, nor an event-driven
simulator will do. You will need do a statistical analysis.

So you need to define "reliable" at some statistical level. Before
throwing out a long string of nine's for your desired synchronizer failure
rate, you also might want to ask about thermal noise, ground noise, EMI,
crosstalk, environmental and package radiation, latent process faults
which passed chip test, solder reliability, etc. etc. and how those
might affect your total system failure rates.


IMHO. YMMV.
--
Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/
#include <canonical.disclaimer> // only my own opinions, etc.

 

[Ralf Hildebrandt]

Tomas wrote:

But I'm having some latches warning I would like to remove.

Ask yourself:
Does the target architecture support latches?
Does your guidelines for this project allow to use latches?
Did you model a latch?

...
I'm getting a 1-bit latches warning on each tmp_recv_inst index
(because I'm probably changing only 1 bit at a time?).

No. A latch is

process(enable)
begin
if (enable='1') then
my_latch<=my_input;
end if;
end process;

In contrast if you model pure combinational logic the signal you write
to has to be assigned a value in every case e.g.

process(enable)
begin
if (enable='1') then
my_output<=my_input;
else
my_output<='0';
end if;
end process;

This means: Somewhere in your case statement there is (at least) one
case of choice, that is not covered.
A latch warning is given by some synthesis tools, because you may have
forgotten one case of choice and the combinational logic you wanted to
bodel became a latch.

The only way I could think about to avoid this latches warning is
this:
...
I'm a real VHDL beginner so I don't know if this *workaround* is
usable and what are the pros and cons.

Do not "avoid latch waningings". Threat them as
* eigther an error report, because there is a latch where no latch was
modeled
* or as a not-so-useful information that there is a latch where you did
model one

Try to model hardware with VHDL - do not "program VHDL". You should know
everytime what will be inferred. This is not hard, because there are
only 3 choices: combinational logic, latch or flipflop.



And last of all: Latches are really nice, but hard to implement because
of some problems that arise while using them (e.g. muxed latch problem).
In most cases a fully synchronous design is preferrable (only comb.
logic and flipflops).

Ralf