what is the problem with latch inference?

[VHDL Guy]

I am in the process of reviewing someone else's code that will be
synthesized in an FPGA. I am not so much concerned with the amount of
space the design will consume on the FPGA as I believe the FPGAs being
used are pretty big, although I realize that best coding styles
recommend that code footprint be as small as possible.

In the code I am looking at, there are multiple situations in which
if/then statements without clock inputs do not have else conditions.

From what I've read on this forum and in some books, I believe that

when synthesized this can cause a latch to be inferred to hold the
value of the signal when not re-assigned.

However, it seems to me that the latch inference will still allow the
design to function as intended. Is this correct?

Why are VHDL code writers cautioned against allowing latches to be
inferred? Do latches cause unreliable circuitry when synthesized in an
FPGA? If so, what are the technical/electrical problems that make
latches unreliable?

Is inference of registers or flip-flops (by clocked if/then statements
without else statement) also a problem along these same lines?

I've been reading this group quite a bit lately and have learned quite
a few things from it. Thanks for your responses and guidance in
advance.

Regards,
Vic

 

[David Ashley]

I am in the process of reviewing someone else's code that will be
synthesized in an FPGA. I am not so much concerned with the amount of
space the design will consume on the FPGA as I believe the FPGAs being
used are pretty big, although I realize that best coding styles
recommend that code footprint be as small as possible.

In the code I am looking at, there are multiple situations in which
if/then statements without clock inputs do not have else conditions.
when synthesized this can cause a latch to be inferred to hold the
value of the signal when not re-assigned.

However, it seems to me that the latch inference will still allow the
design to function as intended. Is this correct?

Why are VHDL code writers cautioned against allowing latches to be
inferred? Do latches cause unreliable circuitry when synthesized in an
FPGA? If so, what are the technical/electrical problems that make
latches unreliable?

Is inference of registers or flip-flops (by clocked if/then statements
without else statement) also a problem along these same lines?

I've been reading this group quite a bit lately and have learned quite
a few things from it. Thanks for your responses and guidance in
advance.

Regards,
Vic

I can't speak with a lot of weight, but in my experience when I
have latches inferred they simulate fine, but an actual synthesized
circuit just doesn't...work right. And I think perhaps different
synthesizers might behave differently. It might even change
from build to build.

In thinking about it, an inferred latch might suffer from
setup and hold instability. We're talking about a non-clocked
output that sometimes wants to change its value. How does
the synthesizer work this out? Perhaps it routes the output
back around to the input, and that becomes the setting for
all states not covered otherwise. So you've got then
combinatorial feedback...which might be dangerous and
unpredictable.

So in general it might be a cause for trouble, and people have
just gotten burned too many times and it's now taboo.

Keep in mind VHDL as a language must be interpreted
by the synthesizer, and there is no guarantee that perfectly
valid VHDL can be reduced to logic gates that exist on
FPGA's perfectly. I think the standard probably only
dictates how a simulator must behave, not what a
synthesizer must do.

Hope this was useful.

-Dave

 

[Peter]

VHDL Guy skrev:

In the code I am looking at, there are multiple situations in which
if/then statements without clock inputs do not have else conditions.
when synthesized this can cause a latch to be inferred to hold the
value of the signal when not re-assigned.

However, it seems to me that the latch inference will still allow the
design to function as intended. Is this correct?

Hi,

Latches is often the result of forgotten ELSE statements and will
generate warnings during synthesis. The problem with latches is hold
time. If input data and the latch enable signal changes on the same
clock edge, the latch may latch a mixture of old and new data depending
on the delay in each signal path.

/Peter

 

[KJ]

Yes, that is correct. Per the VHDL standard (and is generally the case with
software languages too for that matter), the value of a signal will remain
unchanged unless it is explicitly reassigned. So if the 'if' condition is
not met, then the signal will hold it's current state.
In simulation yes, in a real board, possibly but only under 'just the right
conditions'. At best it will fail outright and the designer can work on
fixing it. At worst it will be a persistent 'flaky' problem with symptoms
like...."It works fine for a bit then when it heats up it stops working,
then when I hit it with cold spray it works again....must be a 'heat
problem' with the chip"...and then you'll go off chasing mysterious "heat
problems" that will be far off the beaten path of what the true problem is.
Unless the underlying hardware in the part has an actual hardware latch then
you will have a problem when trying to synthesize a latch from basic logic
because you have no control over timing delays and race conditions. If
there is a built in latch in the hardware for the generic part itself, the
chip designer CAN control timing delays and race conditions and give you a
reliable latch. That's the key difference, the chip designer has control
over things that the VHDL writer does not which are critically important for
making a latch.
The basic process template for a latch is
process(LE)
begin
if (LE = '1') then
Y <= X;
end if;
end process;

An alternative exactly equivalent representation (that you should also look
for in your code by the way) is
Y <= (LE and X) -- #1
or (not(LE) and Y); -- #2

The problem is that there is an inherent race condition when LE switches
from '1' to '0' and line #1 is going to no longer be true and has to hand it
over to line #2. What if the logic needed to implement #1 is 'faster' than
line #2? Because line #1 will be false (because LE is switching from 1 to
0) then Y will get to 0 and line #2 (the slower path) will latch Y with a 0.

If you remember Karnaugh maps you can 'solve' this problem by adding
redundant logic terms and write
Y <= (LE and X) -- #1
or (not(LE) and Y) -- #2
or (X and Y); -- #3

This third form has a 'cover' term line #3 that solves the race condition.
'LE' switching is no longer causing a race condition because if the input
'X' and output 'Y' are both '1' then 'Y' will remain a '1' regardless of
what 'LE' is doing. The problem is that any synthesizer will be able to
spot it as a redundant logic term and will reduce it out taking you right
back to the previous form...which has the race condition.

The VHDL designer might then be tempted to write it with the cover term and
add signal attributes to prevent 'Y' from being optomized. The problem with
that approach is that those attributes are always vendor and tool specific,
if you change either one then the "don't reduce this darn it" attribute will
be ignored.

You'll also have the additional task of physically verifying (for at least
one instance of your latches but probably all) that the final fitted code is
exactly what you intended since, if you use the attribute incorrectly (like
missspeellll it somewhere) it will be ignored without any warning.

If your particular part DOES have a native hardware latch, then you need to
physically verify that ALL latch instances result in the proper final fitted
equations. For the above set you'll probably see something like
Y.LE = LE; -- This is the LE input to the latch
Y.EQN = X -- This is the 'D' input to the latch
As I said, you'll need to do this with each instance of a latch to make sure
that there isn't something in the way you coded it in one place that
confused the fitter. The most common way to confuse some is if you have
something like "if ((This or That) = '1') then". The tool might synthesize
it to what you want but you'll have to check.

If that's how you want to spend your engineering man hours, that's up to
you....but I'm sure it's not. So, that's why you never want to use a latch
inside code destined for a CPLD or FPGA.
No, because all CPLD/FPGAs have flip flops hardware built in so they won't
cause the synthesis tool to try to build a flip flop out of logic gates as
it can do with a latch. Once again, it is the flip flop designer for the
chip itself that has to deal with the timing but they have the ability to
control timing but the VHDL designer trying to USE the flip flop does not.

By the way, as I mentioned earlier, besides the 'process' form of latch
inferrence, you need to look for any case where the output of an equation
shows up on the right side of the equation as well (as I demonstrated in the
'alternative' form). Those are both the exact same latch. To take it
further you also have to consider that the following is a form of latch
also.

Y <= (LE and X)
or (not(LE) and Z);

Z <= Y;

Here it is not much of a stretch to see it as a latch, but the latched
signal 'Y' does not upon first inspection appear to be a latch since it does
not appear to depend on it's own value as input. The point here is that
there might be any number of equations in the logic path much more than just
"Z <= Y". Just so you don't tear your hair out trying to find all of this
though, every synthesis tool should be able to catch this and report a
warning. It will happen in one of two forms: either a warning about an
inferred latch (which they implicitly are telling you is 'bad', hence the
'warning') or if nothing else in the timing analysis it will report about a
'combinatorial loop' (which is a timing path that exists where you have a
combinatorial loop of logic without a flop anywhere in the path). In either
case it's a 'warning' not an 'error' so you will get an output file that you
can program a part with. Like most warnings though, this is actually a
design error....so fix it. The point is that these things can be caught
most easily by perusal of synthesis report files much easier than by code
inspection because the synthesis report will always catch everything, the
code inspection might overlook something.

KJ

 

[Ralf Hildebrandt]

VHDL Guy schrieb:

In the code I am looking at, there are multiple situations in which
if/then statements without clock inputs do not have else conditions.
when synthesized this can cause a latch to be inferred to hold the
value of the signal when not re-assigned.

You have to decide if you want a storage element or not. This is nothing
that can be left to a discussion about area or something else. It is a
very big difference if you describe something pure combinational or
something that includes storage elements.

I write storage elements, because I mean flipflops AND latches. A good
hardware designer knows _every_ storage element in his design and checks
the synthesis report if exactly these storage elements are inferred (not
more, not less).

However, it seems to me that the latch inference will still allow the
design to function as intended. Is this correct?

Yes. Latches are not something "evil" - they are elements like all the
other circuit elements with special purpose and special behavior.

Nevertheless latches require careful design. For flipflops there are
automatic checks of setup- and hold-time violations. For latches such
stuff does not exist. A hardware designer has to take care that the
latch input does not change short before the latch-enable is turned off.
This is dangerous, because a lot of people are too lazy to think about
this risk. For the others a latch is a wonderful storage element
(smaller and less power consumption than flipflops). But flipflops and
latches cannot exchanged because they have different advantages and
drawbacks.

Why are VHDL code writers cautioned against allowing latches to be
inferred?

I have written about the lazy people. The same holds for the beginners.
Latches provide traps and pitfalls. If you know them, you can avoid them.

A lot of FPGAs do not have latches included. Therefore latches are build
out of combinational loops. This may lead to problems.

If so, what are the technical/electrical problems that make
latches unreliable?

The "problem" is the behavior of a latch itself: Latches are open for
the data input as long as the latch-enable is active and therefore they
are transparent. This means the output changes too! And as I have said
it is dangerous if the data input changes short before the latch-enable
is turned off. No one can tell you then, what value is stored in the
latch. The similar behavior for flipflops can be detected using setup-
and hold-time checks.

Is inference of registers or flip-flops (by clocked if/then statements
without else statement) also a problem along these same lines?

A register is a storage element. A storage element can be a latch or a
flipflop.

The inference of storage elements is never a problem - except you did
not want them and know why they are inferred.


Most synthesis tools report warnings when they infer latches, because it
is easy to make a mistake while describing a combinational process and
getting an unwanted latch because of this mistake. Latches in FPGAs may
be a problem - depending on the FPGA. And a lot of companies have design
rules, that do not allow the usage of latches.

I use latches whenever it is possible, but the design has to be done
very carefully.

Ralf

 

[KJ]

Yes. Latches are not something "evil" - they are elements like all the
other circuit elements with special purpose and special behavior.

Nevertheless latches require careful design. For flipflops there are
automatic checks of setup- and hold-time violations. For latches such
stuff does not exist. A hardware designer has to take care that the
latch input does not change short before the latch-enable is turned off.
This is dangerous, because a lot of people are too lazy to think about
this risk.

Setup and hold time relative to the latch enable is important but the much
bigger risk with using latches inside FPGA/CPLDs where the targetted device
does not have a hard latch and the latch must be cobbled together from logic
blocks is the inherent race condition in the resulting logic which is the
predominant failure mechanism that I've seen even when setup and hold time
were easily met but the output went to 0 a Tpd after the latch signal went
low....and all you can do then is use non-portable vendor/tool specific
attributes to help you out.

I have written about the lazy people. The same holds for the beginners.
Latches provide traps and pitfalls. If you know them, you can avoid them.

Hence the reason for the caution....you don't know what you don't know. For
example, even if you ae aware of setup/hold timing analysis but did not know
about the the race condition problem then you wouldn't know that you're
heading for problems if you use latches.

A lot of FPGAs do not have latches included. Therefore latches are build
out of combinational loops. This may lead to problems.

Without resorting to vendor/tool specfic attributes being added to the code,
I would say that it WILL lead to problems.

KJ

 

[Paul Uiterlinden]

KJ wrote:

Thumbs up for your informative post!

On small thing: you forgot the data input in the sensitivity list.

The basic process template for a latch is
process(LE)
begin
if (LE = '1') then
Y <= X;
end if;
end process;

This should be:

process(LE, X)
begin
if LE = '1' then
Y <= X;
end if;
end process;

 

[KJ]

KJ wrote:

Thumbs up for your informative post!

On small thing: you forgot the data input in the sensitivity list.

This should be:

process(LE, X)
begin
if LE = '1' then
Y <= X;
end if;
end process;

Sometimes it can be really easy to spot the work of somebody who hardly ever
uses a process sensitivity list that consists of anything more than 'Clock'.
Good catch.

KJ

 

[Andy]

Setup and hold time relative to the latch enable is important but the much
bigger risk with using latches inside FPGA/CPLDs where the targetted device
does not have a hard latch and the latch must be cobbled together from logic
blocks is the inherent race condition in the resulting logic which is the
predominant failure mechanism that I've seen even when setup and hold time
were easily met but the output went to 0 a Tpd after the latch signal went
low....and all you can do then is use non-portable vendor/tool specific
attributes to help you out.

Hence the reason for the caution....you don't know what you don't know. For
example, even if you ae aware of setup/hold timing analysis but did not know
about the the race condition problem then you wouldn't know that you're
heading for problems if you use latches.

Without resorting to vendor/tool specfic attributes being added to the code,
I would say that it WILL lead to problems.

KJ

Not only do many FPGAs not have built-in latches, but their static
timing analysis tools are not suited to analyzing both setup/hold to
the latch enable signal, AND the combinatorial path delay through it
(to whatever the next storage element might be).

The recommendation to always include elses with ifs is only a partial
solution, and it not sufficient in itself. A better approach when
coding combinatorial processes is to make default assignments right at
the top of the process, so that no matter what, when the process
triggers, every signal will be assigned something. This is a much more
foolproof method, and is more easily auditable in reviews.

The best way to avoid latches, IMHO, is to avoid combinatorial
processses altogether. Use variables in clocked processes.

Andy

 

[fp]

I am in the process of reviewing someone else's code that will be
synthesized in an FPGA. I am not so much concerned with the amount of
space the design will consume on the FPGA as I believe the FPGAs being
used are pretty big, although I realize that best coding styles
recommend that code footprint be as small as possible.

In the code I am looking at, there are multiple situations in which
if/then statements without clock inputs do not have else conditions.
when synthesized this can cause a latch to be inferred to hold the
value of the signal when not re-assigned.

However, it seems to me that the latch inference will still allow the
design to function as intended. Is this correct?

Why are VHDL code writers cautioned against allowing latches to be
inferred? Do latches cause unreliable circuitry when synthesized in an
FPGA? If so, what are the technical/electrical problems that make
latches unreliable?

Is inference of registers or flip-flops (by clocked if/then statements
without else statement) also a problem along these same lines?

I've been reading this group quite a bit lately and have learned quite
a few things from it. Thanks for your responses and guidance in
advance.

Regards,
Vic

See page 16 of

http://academic.csuohio.edu/chu_p/rtl/chu_rtL_book/silde/chap08_1.pdf

It shows how delay can lead to oscillation and
what can go wrong for an ill-designed latch
(or a circuit with combinational loop).

S. C.