verilog - Why are inferred latches bad?

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.

Answer

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.