VHDL and Latch

In FPGAs and CPLDs there is not much need for a latch because a flip flop will do just fine.

There is no guessing involved. Certain coding styles infer a latch, just like others infer a flip flop and still others infer a block of memory.

Weng, First, 1076.6-2004 introduces an attribute named combinational. For a compliant tool, when this attribute is applied to a process label and the process creates a latch then a synthesis tool shall generate an error.

So request that your vendor implement the standard (if they have not already). Vendors will implement what their user community wants. If you want this, you must make sure you talk to your vendor.

That is not true. While latches are not supported in most modern FPGAs and where discouraged to use in older families, in ASIC design it is very common to split D-Flip-Flops into two latches distributed through the pipeline. Also, VHDL ist not only used for synthesis. It was intended to model systems and there clearly are systems that behave like a latch so there must be a way to model them.

Most synthesis tools issue a warning in the cases that you describe which is an adequate reaction to the situation: The tool accountered legal code of which it knows that it is often written unintentionally.

Kolja Sulimma

Kolja, good point.

To follow up on this point a bit for the other readers. The reason that latches are discouraged FPGA/CPLDs but not so in ASICs is because in the ASIC world they actually have a hard set of logic that gets inferred from the code that generates a latch whereas in the typical FPGA/CPLD world you do not. Instead the latch gets created by cobbling together the LUTs or macrocells. The problem with the cobbling together approach is that you have virtually no control over the timing inside the FPGA/CPLD and yet a latch will have setup and hold timing requirements that you will have no way to guarantee.

If FPGA/CPLDs cobbled together LUTs to create flip flops the same argument could be made for not using flip flops. But since FPGA/CPLD/ASICs all have flip flops implemented as hard logic you don't have this issue. Also, if the target device does have a hard latch as a resource that can be used then the use of latches is just fine also.

Kevin Jennings

Weng Tianxiang schrieb:

I do it every day. Latches are only half as big as flipflops and are not triggered by a highly active clock. They only need their enable signal. This makes them then 1st choice for small low-power circuits.

Using latches means thinking very well about the behavior of the circuit. Hazards, the common muxed-latch-problem and other stuff has to be considered.

signalA is not assigned in the else-branch. Therefore you get a latch, because this process is not clocked. This is a bad way to code a latch (because you easily trap into the muxed-latch pitfall) but why this should be an error? All synthesis tools will report that signalA has inferred a latch.

Simply put because it is not an 'error' to write code that infers a latch. To presume that every latch is 'unintended' would be wrong.

If you choose to use that attribute and find a tool that supports it then by all means use it. But keep in mind that if you forget to use the new attribute (because people are human) that you can still end up in the same situation. It's up to you if that's the coding style you prefer to use to avoid unintended latches, personally I prefer other coding styles but the attribute is at least an improvement and gives another method which is good.

No matter which of these two methods you use, you can still get an 'unintended latch' with the following type of code which infers a latch

Q This is another big problem: I don't know how ASIC people generate a

That doesn't preclude them from inferring a latch in other ways.

No idea what you mean by this...but reading on

Unless the underlying hardware has a hard latch available as a resource to use and most (if not all) FPGAs do not, then I would agree that there is no reliable way to generate a latch inside an FPGA in any language, not just VHDL. The lack of latches in FPGAs though has nothing at all to do with VHDL or any language it is simply recognition by the FPGA suppliers that there is very little demand for a hard latch inside the FPGA. A flip flop would have the exact same coding issues, the only reason it's not a 'problem' is because there are hard flip flops inside the FPGA.

The 'problem' with inferring any storage element (latch, flip flop, big hunk-o-memory, fifo, etc.) is when the underlying hardware doesn't directly support the inferred element and it needs to be cobbled together from basic logic blocks. In the FPGA/CPLD world, it is very difficult to meet internal setup, hold time and 'no glitching' requirements between two arbitrary signals.

Remember also, that you can build ANY logical element strictly from NAND gates or NOR gates....so in theory you could write your code using only these two building blocks. Were you to do so and target an FPGA, it would most certainly fail if that design had any sort of storage.

Same as any other logical description....it gets mapped to whatever internal resources exist in the device (LUTs, macrocells, flip flops, latches, whatever the target device supports).

You're welcome.

Kevin Jennings

Hi KJ,

1. Q

That equation is written exactly as-is and would work in theory. Glitches on Q while C goes from 1 to 0 may break the feedback loop or make it metastable in practice.

Another VHDL way of putting it would be:

Q using latch primative to call it. But it is hard to refer to it in

Latches: "if somesig='1' then ... end if;" Latches(2): see equations and process above

FFs: "if clk='1' and clk'event then ... end if;" FFs(2): "if rising_edge(clk) then ... end if;"

That seems like plenty straight-forward VHDL to me. Latches are active on levels, FFs are active on edges. Simple.

Xilinx devices do not have dedicated latches BUT they do allow you to program a slice FF to bypass HALF of it so it can be used as a latch. As far as power is concerned though, the whole FF is still connected to the clock so you most likely won't be saving any power here. BTW, the configuration logic that goes behind FPGA FFs uses more surface area than the FF itself and the "latch bypass logic" probably uses nearly as much power as a pure FF.

To reach high clock speeds, FPGAs and ASICs need their pipeline storage elements to be able to forward values from D to Q with as little setup, hold and settling time as possible to maximize timing margins between clock edges. This is most effortlessly and reliably achieved with FFs, hence the dominance of FFs in the world of high-speed digital systems and the FF-oriented nature of FPGAs even though they cost a little more surface area and power.

Simply put, FFs are the path of least unnecessary pain.

If you want lower power FPGAs, some flexibility has to be sacrificed. If Xilinx stripped the latch option from slice FFs, it would reduce the slice FF cells' power and size by 15-20% while making them a little bit faster. I wonder how many would have a problem with this.

It's the same old transparent latch that we've been talking about all along. The following forms are exactly equivalent logic and will result in the exact same synthesized result. #1 -- Traditional form of writing a latch process(C, D) begin if (C='1') then Q mean is VHDL really lacks the statement element to refer to a latch in

I've shown above four different forms for inferring the exact same latch (i.e. synthesizes to the exact same thing). Which form you prefer (or if you prefer to make up your own) to use is up to you. Making up a new method though will not prohibit the earlier forms from being used and outlawing the other forms gets in the way of people who do use latches and are doing so in a way that they can control the various issues so you're not helping them by outlawing their method.

Kevin Jennings

Just thought I'd add to this thread that, all other things being equal, latches generally have less setup time than FFs. This can be important for some circuits. HTH, Syms.

Hi KJ, Thank you very much for your points.

Your answer really opens my eye and expand my knowledge range in FPGA and VHDL !!!

Weng

On Mar 7, 5:57 am, "Symon" wrote:>

Symon, I disagree. The set-up time of a flip-flop is really the set-up time of the master latch (the last chance for input data to become locked up in the latch when the clock is going High.) The flip-flop's slave latch has nothing to do with the set-up time. Therefore I see no reason for the flip- flop to have a longer set-up time than a simple latch. The evidence seems to be anecdotal... Peter Alfke

Hi Peter, Yes, thinking about it again, you're absolutely right. I dredged back though my memory and the situation I so badly recalled was a double data rate circuit near the toggle limit of the part. I needed to synchronise phase alignment between two signals, one in the rising and one in the falling edge clock domains. To do this I had the output of a falling edge FF feeding the input of a rising edge FF. By changing the falling edge FF to a latch (transparent when clock is high), I gained extra set-up time for the rising edge FF, as the latch passed data through a little earlier. Many thanks for correcting me, and putting the record straight. Best regards, Symon.

I've come up with this approach myself, subsequently seen it mentioned in an app note, and now find you've concluded the same circuit is useful in this situation.

More engineers should be exposed to this one application where a latch is indespensible. Without it, DDR domains can get messy.

The one sad thing about it, in my opinion, is that the Xilinx timing tools don't treat this case well. My recollection is that the setup is referenced to the wrong edge giving me no chance to get clean numbers by only including latch_d_q path tracing.

- John_H

Hi John, Could you please tell which application note you are talking about.

Thank you.

Weng