My compiler complains about inferred latches in my combinatorial loops (always @(*), in Verilog). I was also told that inferred latches should preferably be avoided.
What exactly is wrong with inferred latches? They certainly make combinatorial loops easier to write.
A "latch" is different from a "Flip-Flop" in that a FF only changes its output in response to a clock edge. A latch can change its output in response to something other than a clock. For example, an SR-Latch has a set and a reset input and if either of them are active then the output can change. Where as an SR-FF only responds to a set or reset when there is also a clock edge.
In an FPGA, you want your logic to be fully synchronous. Meaning that all storage elements (like FF's) are all clocked from a single clock source. Anything that is asynchronous to that clock needs to be treated very carefully otherwise timing errors will occur.
A latch is basically an asynchronous storage element. It has no clock input, and thus cannot be synchronized with any clock. I should note that there are FF's with asynchronous reset and reset inputs, and these should be treated with the same care as normal latches.
Going into all of the timing issues that latches can cause is way beyond what can be covered here, but let me give you one example:
Let's say that you have an SR-Latch, and you want it to be set every time an 8-bit counter reaches a certain value. I'm not sure what the Verilog code would be, but in VHDL the code is: set <= '1' when count="11010010" else '0'; That set signal goes to the set input on our SR-Latch.
The logic that is generates is purely combinatorial; a mix of and-gates, or-gates, and inverters (Or LUTs). But the signal paths through that combinatorial logic is not always perfect and the "set" signal could have glitches on it. The signal path through a particular group of gates could take longer than another group, causing the set output to go active for a brief moment before the output settles down into the final state.
This output glitch could cause our SR-Latch to be set, even though it wasn't supposed to. If we switch from an SR-Latch to an SR-FF, clocked off the same clock that the counter is, then the SR-FF will wait for one whole clock cycle before changing state. In essence it will wait for the set signal to settle before looking at it.
If the paths through combinatorial logic for the set signal is just routed differently (causing different delays), then the glitch behavior will change too. The logic might work fine, but then because you changed something entirely unrelated this logic is routed differently and so the bug pops up. Temperature and voltage will also change the signal timing, and thus can change the glitch behavior.
This uncertainly in the timing is why you should avoid latches in your logic. FF's are much safer to use. This is why your compiler is warning you about latches, since it is easy to mistakenly make a latch and you probably don't want it there anyway.
Of course, sometimes latches are required. You just have to use them very rarely, only when absolutely required, and then you must design the logic right so there are no glitches possible.
What makes an inferred latch?
For combinatorial logic, the output of the circuit is a function of input only and should not contain any memory or internal state (latch).
In Verilog, a variable will keep its previous value if it is not assigned a value in an always block. A latch must be created to store this present value.
An incomplete if-else statement will generate latches. An if-else statement is considered "incomplete" if the output state is not defined for all possible input conditions. The same goes for an incomplete case statement, or a case statement that does not have a default: item.
Why are inferred latches bad?
Inferred latches can serve as a 'warning sign' that the logic design might not be implemented as intended. A crucial if-else or case statement might be missing from the design.
Latches can lead to timing issues and race conditions. They may lead to combinatorial feedback - routing of the output back to the input - which can be unpredictable.
To avoid creating inferred latches:
Some parts paraphrased from "FPGA Prototyping by Verilog Examples" by P. Chu
Latches are very tricky to use in FPGAs or CPLDs, so many people just avoid them completely. One of the reasons is that many FPGAs don't have a built in latch, so they are made out of logic gates - this can cause nasty timing issues.
Also you don't have any control over timing delays and race conditions when using a latch (unless there is a native element)
I would advise against using latches unless you absolutely can't do without them (e.g. time borrowing to meet a needed max clock frequency) and use coding techniques to make accidentally inferring latches less likely.
Sequential logic designs constructed by using combinatorial logic and feedback generally make an assumption which would seem reasonable when using physical gates: that a gate's output will not change in response to a change in input, until sometime after the input has actually changed. There are some occasions where that assumption may not hold when using real gates (e.g. if a fast NOR gate and a fast inverter are both driven by a signal which rises slowly from VSS to VDD, and if the inverter switches at 1.2 volts while the NOR gate doesn't switch until 1.7 volts, the NOR gate might see the output of the inverter go low before it sees that the slowly-rising signal has gone high) but such problems can generally be resolved by adding a buffer whenever a slowly-changing signal is routed to more than one destination. Unfortunately, such an assumption might not hold at all with an FPGA.
The problem is that unless explicitly instructed otherwise, an FPGA compiler may arbitrarily replace a combinatorial circuit with a totally different circuit which has the same steady-state behavior, but may have entirely different timing. For example, suppose a complex combinatorial function F takes six inputs U through Z. F is fed directly to circuit P, and (F NAND Z) is fed to circuit Q. The compiler might realize that the value fed to Q will only depend upon F when Z is high, and may compute a function F' which is like F except that Z is assumed high; Q may then be fed with (F' NAND Z) rather than (F NAND Z). It would be entirely possible that the most efficient realization of P would have five gate delays, but the most efficient realization of Q would would only have two. Thus, even though it would look as though Q should change a gate-delay later than P, it might change two gate-delays earlier.
If a circuit has a combinatorial feedback loops, an FPGA compiler will have to add physical signal nodes which will, physically, have a positive delay (a zero-delay feedback loop can't exist in the real world), but there's no guarantee that such nodes would be added in the places that are necessary to make the circuit behave as desired. Nor is there even a guarantee that a slight change to the design won't cause the compiler to change from an arbitrary placement that happens to work in the real world, to a different arbitrary placement that happens to fail.
Details about how to catch a latch in design is briefly explained in this link.
