# 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.

• It would be good to include a HDL example of what you are doing – shuckc Aug 28 '13 at 13:15
• I've noticed this question has been cited a couple of times recently. For anyone who's not an expert coming this way, note that all the answers, apart from Oli Glaser's, are some combination of incorrect and/or unhelpful. – EML Dec 1 '15 at 12:27
• It's less that inferred latches should be avoided and more that transparent latches in general should be avoided unless you know exactly what you are doing (note that quartus somewhat misleadingly gives the "inffered latch" in some situations that don't involve transparent latches and are perfectly safe). – Peter Green Dec 18 '15 at 10:40

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.

• I would expect that if one explicitly specifies a latch in verilog or other language, and if one designs a circuit so that it would work correctly with any combination of combinatorial delays feeding the latch (meaning that whatever was generating the signals that would be combined for the latch, would do so in such a way that even with the worst-case combinations of zero-delay logic paths and maximal-delay logic paths, the timing requirements for the latches would still be met), a synthesizer should generate a working circuit where the latch itself has non-negative delay. If, however... – supercat Aug 23 '12 at 21:17
• ...one uses combinatorial logic and feedback without specifying any nodes that must have non-negative delay, just about anything could happen. I appreciate that synchronous logic is easier to design than async, but many devices need to shut down clocks when they sleep so as to save power, without being totally dead. It might be interesting to have a device which was totally synchronous, but had associated with each pin a couple of logic outputs for "run if pin is high" and "run if pin is low", along with the ability to generate a clock if any pin indicated one was needed. – supercat Aug 23 '12 at 21:22
• Such an ability would mitigate much of the need for async logic, since an input that arrived while the device was sleeping could power up the internal oscillator and circuitry just long enough for the input to be processed and acknowledged. Such a feature would be much more versatile than having a single "wake-up" pin, but single-wakeup designs seem the norm. Would a multi-wake-up approach such as I described consume excess silicon? I would think the silicon requirement would be pretty minor compared with everything else on-chip. – supercat Aug 23 '12 at 21:25

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.

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:

• Include all the branches of an if or case statement
• Assign a value to every output signal in every branch
• Use default assignments at the start of the procedure, so every signal will be assigned.

Some parts paraphrased from "FPGA Prototyping by Verilog Examples" by P. Chu

• "FPGA Prototyping by Verilog Examples" is a good book to learn practical Verilog for Synthesis. It has some good example designs from basic combinatorial stuff to basic sequential, leading up to useful designs like UART, VGA, soft core processor (Picoblaze) and even a Pong game. It also covers basic testbench and simulation. @Randomblue, you should grab a copy if you haven't got it already. I believe he also did a VHDL version too. – Oli Glaser Aug 23 '12 at 20:16

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.

https://www.doulos.com/knowhow/fpga/latches/

• Welcome to EE.SE! You could improve your answer by including some relevant details from the link. This ensures that your answer is high quality even if the original page disappears. – David Apr 12 '14 at 22:04