I always hear from FPGA designers that latches are "dangerous" and that it' s very important avoiding them. I wonder what are the technical risks resul ting by using latches. As far as I understand, the main problem is that FPG As don't have built in hard latches so the synthesizer has to implement it from logic blocks and then the race condition in the resulting logic is har d/impossible to be analyzed. Is this main disadvantage latches? are there any other issues regarding lat ches which shall be considered?
It is not that latches are inherently bad. The problem is that they can be inferred unintentionally. The only time I remember using a latch in a design was way back when the 8085 CPU was around. I recall that they multiplexed the address with the data or with itself (upper/lower) and to get the best address setup time a latch was used, 74LS373 rather than the 74LS374 register. The address would flow through ahead of the edge of the clock that would hold it giving more address setup time.
I believe that most programmable logic will implement latches ok. I'm not sure what race condition you are referring to. The only problem I can see is that if you use them in the wrong place they will let signals flow through successive latches rather than holding like registers will do. Oh yes, the static timing analysis program is incapable of calculating any timing analysis on them, so that is a real problem.
I have never needed a latch in any HDL design I have worked on. Do you see a use for latches in your design?
What is 'dangerous' is not the latch in itself, rather the implicit instantiation of a latch because of an incomplete assignment. This is usually a sign something has been 'forgotten' by the designer, hence the danger.
AFAIK, timing analysis may have problems because it performs setup/hold times verification based on clock propagation. If your enable signal is slower than the data in your latch you'll have issues that are hard to spot during timing analysis.
Not true, there are devices with built in latches (ex. ProAsic from Microsemi) that are readily available even for automatic triplification to enhance radiation tolerance.
You've got it almost correct. The only mistake is that it's not that they are 'hard/impossible to be analyzed' though, it's because the race conditio ns will cause the latch to fail if constructed out of logic blocks rather t han a hard latch. A flip flop would fail in the same way if constructed ou t of logic blocks as well.
t's very important avoiding them. I wonder what are the technical risks res ulting by using latches. As far as I understand, the main problem is that F PGAs don't have built in hard latches so the synthesizer has to implement i t from logic blocks and then the race condition in the resulting logic is h ard/impossible to be analyzed.
atches which shall be considered?
RIK and HTH thanks for your reply,
RIK, regarding your question- in some cases while using combinatorical logi c based state machines, i would like that some signals will keep their curr ent values as a default (unless some defined conditions are met). I think t hat this will result with latch since we get an asynchronous process (async hronous decoders for the next state and for the output registers) with a si gnal that its default value is its current value (i'm not that experinced w ith asynchronous design so please correct me if i'm wrong...). I agree that latches are not sound that usefull but sometimes i find myself choosing not to use asynchronous processes in order to avoid from inferred latches.
gic based state machines, i would like that some signals will keep their cu rrent values as a default (unless some defined conditions are met).
This will result in a design that fails. If you're lucky it just never wor ks, if you're not lucky you find that it doesn't work as you're manufacturi ng is trying to build 1000 boards and find they are 'flaky'. Take what you think to be a 'working' design' and spray some cold spray on the part and watch it fail.
If you're doing FPGA designs and you're using a part that does not have har d latches, then you would be best off to abandon any use of combinatorial s tate machines before you get burned.
t's very important avoiding them. I wonder what are the technical risks res ulting by using latches. As far as I understand, the main problem is that F PGAs don't have built in hard latches so the synthesizer has to implement i t from logic blocks and then the race condition in the resulting logic is h ard/impossible to be analyzed.
atches which shall be considered?
Rick and Al thanks for your reply,
RIK, regarding your question- in some cases while using combinatorial logic based state machines, I would like that some signals will keep their curre nt values as a default (unless some defined conditions are met). I think th at this will result with latch since we get an asynchronous process (asynch ronous decoders for the next state and for the output registers) with a sig nal that its default value is its current value (I?m not that exper ienced with asynchronous design so please correct me if I?m wrong.. .). I agree that latches are not sound that useful but sometimes I find myself choosing not to use asynchronous processes in order to avoid from inferred latches.
There is a difference between an "asynchronous state machine" and "asynchronous" process included within a 2-proces (synchronous) state machine. The latter is often used, although generally not preferred by serious FPGA designers. If your decode logic is just for the "next" state, and the current state comes from a clocked register (edge-triggered flip-flop), then the correct way to retain the current state is to assign the output of the flop to the next state, rather than assigning next state to itself, which infers a latch.
Why do you want to implement combinatorial logic based state machines in the first place? What is the use case where there's a need for such an FSM w.r.t. clocked FSM?
A signal whose 'default value is its current value' is hard for me to picture. Default is tipically that value the system is at rest when coming up, how can this value depend on the current value?
Think about the behavior you want to attain in the first place and only then reason in terms of asynchronous and/or synchronous.
Remember always that timing analysis is critical for the *correct* functioning of your logic. If your design fails to meet design constraints it will likely fail the 'cold spray' test KJ mentioned...sooner or later!
When you present registers to be consumed or manipulated by a microprocessor ( say, memory mapped ) , are those what you are calling registers, or are they latches?
Or is it "could go either way"?
It's been a while but I remember them being a register with some different attributes form, a purely internal register.
As well as I remember, the 373 was always used for address lines, and the 374 usually for data lines.
Well, in the FPGA case you usually have edge-triggered FFs for free.
As well as I know it, in the days before TTL (or probably ICs in general) it was not usual to use edge-triggered (master-slave) FFs. Processors often had two (or more) phase clocks to keep data from going where it wasn't supposed to go. It takes a lot more transistors to make an edge-triggered FF.
See
formatting link
for more.
In the early days, the term was usually latch, I believe that flip-flop didn't come until somewhat later, maybe not until IC days. (Bistable multivibrator was used for some years, too. Monostable multivibrator is now usually known as a one-shot, and astable mutlivibrator is an oscillator.)
I am working on some designs based on old logic. Latches were not uncommon in the TTL days. The favorite display logic, such as for a frequency counter, was the 7490 ripple counter, 7475 latch, and then 7447 BCD to 7-segment decoder. (Earlier, the 7441 and Nixie (tm) tube.) Reset the counters, let them count with the latch open, (users can see the numbers change) then close the latch.
Similar the way split times are done with a stop watch. The counters can keep running, but you latch the data once in a while. (For faster counts, there could be some race conditions.)
"Transparent latch" and "edge-triggered master-slave flip flop" are pretty unambiguous. Everything else, you can't be sure.
That isn't always true, but you do have to do it right. In the pre-TTL days it was usual to have a two-phase clock. It is then easy to avoid race conditions with appropriate non-overlap of the phases.
Many early microprocessors used a two-phase clock, and some even four phase. (Remembering from years ago, the TMS9900 uses four.)
But yes, with one clock signal you are pretty much stuck.
To make an edge-triggered FF, as I understand the design, you need logic with different threshold voltages. You don't get that with FPGA logic.
Creating a latch has nothing to do with two-phase clocks. In order to reli ably create a latch out of logic you need to specify redundant logic terms and then insure that the logic gets implemented exactly that way, like this ...
I can't say I understand your question on several points. I don't know what it means to "consume" a register.
The definition of a register is a storage element that is edge sensitive while a latch is level sensitive. Assert the enable of a latch and it passes the data input to the output. When the enable is removed it remembers the last value on the output. A register output is only affected by sampling the data input on the clock edge (rising or falling but not both) and presenting it to the output.
You are thinking old school where the logic is made up of gates. In an FPGA the programmable logic is made from LUTs which are memory elements programmed at configuration time and so are fixed 1s and 0s during operation and multiplexors made from transmission gates. Some esteemed Xilinx representatives pointed out that the transmission gate multiplexors can be constructed to assure that the transition of a single input will *not* cause a glitch so that
I can't say I follow your point. A register keeps its value as a default if there is no change specified. If you are talking about an asynchronous state machine, then there is no clock at all. That is a different animal altogether and not so easy to do in an FPGA. Yes, this will result in the formation of what would be considered a "latch", but without a clock!
The inputs to the async FSM each trigger transitions and as Kevin was discussing, require coverage terms for each and every transition. I remember learning this in college and *never* using it in practice. One colleague used an async FSM chip in a design many years ago. I've never seen an async FSM since unless you count an RS FF as an async FSM, lol.
The 'esteemed Xilinx representatives' probably did not say all of that. Th ey might have stopped somewhere at '..to assure that the transition of a single input will *not* cause a glitch'. But also note that you're relying on the word of a rep here to somehow guarantee that the final synthesized logic will be created in such a way that there will only be one switching i nput to that LUT. Remember, this is a stripped down example. The actual c loud of logic that generates 'D' and 'EN' are not necessarily signal inputs to the LUT. There might not be a discrete 'D' or 'EN' signal input...unle ss you go through the trouble of creating and correctly applying synthesis attributes (which I'm not recommending...I recommend to avoid all forms of transparent latch type of stuff). Even if 'D' and 'EN' are discrete, I wou ldn't rely on somebody's word that the logic hazard can be safely avoided i nside a LUT.
Draw the Karnaugh map and look for the logic hazard. That is what the last term covers. It doesn't matter whether the implementation is in gates, CP LD product terms or FPGA lookup tables. If you want a reliable latch you'l l cover the hazard with the cover term.
Do you have a reference to support that specific statement?
I've only seen them fail, but granted I was mostly debugging someone's inte rmittent problem to start with. But I've also taken 'working' designs with latches and made them fail with cold spray that did not fail when the desi gn was changed to use flip flops.
Actually he did. If you dig around you can probably find the thread. I think it was the late Peter Alfke discussing exactly this issue of latches in the logic fabric.
Yes, I can guarantee there will be only one switching input to the LUT, the CLOCK! Even for a latch there is a setup and hold time spec so the D input must be stationary during the time around the enable being deasserted. It doesn't matter how many other signals go into making that D input. They must *all* be stationary during the setup/hold time window.
Now you are in denial. I explained how the capacitance of the output node acts as a memory element during the switching time where there can be a short interval when *all* transmission gates are off so the node is not driven. That is how the cover term is provided, by a memory element.
Me, I've just explained it to you. If you want more proof, find the posts by the Xilinx people.
What parts were these in? I would like to know more about this. The info I had was from Xilinx and only applied to Xilinx parts of course. Since I have never needed a latch I have not done any searching to see if this is more generally supported in FPGAs.
Oh, that is what he was asking about? OK, yes. I didn't figure out that is what he meant.
The way I think about it is, that when one input changes, and the output doesn't change value, there won't be a glitch.
That isn't obvious if you think about the usual way of making multiplexers.
I agree. But he did also point out that the current tools aren't so good at figuring out the timing. You want to know how fast you can run the clock, and still get the right output.
If you design with the usual edge triggered FFs, it is all done almost automatically. A little more work in this case.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.