Are latches always bad?

[hal9001]

I want to make an asynchronous state machine based on how a pins change similar to quadrature encoding. Im using Spartan 6 and get the warning

Found 1-bit latch for signal . Latches may be generated from incomplete case or if statements.

And

Gated clock. Clock net is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop.

First question. If this design moves as is from Spartan 6 to Artix or another brand of FPGA, will it have problems?
Second question. Should latches and asynchronous design be avoided or is there ever a reason to use asynchronous designs?


Cheers!

[RoGeorge]

In FPGA design, anything asynchronous is to be avoided.  Might work, but it is a bad practice.  Might be tempting to use latches, or something asynchronous, but their pitfalls are almost never justified to be used in an FPGA.

Use synchronous design instead.  No matter which manufacturer, if it doesn't have a clock and if it's not a synchronous design, then most probably you are doing it wrong.

Find another quadrature encoder that has a synchronous design.

[laugensalm]

The general problem with asynchronous designs where several pins determining a next state may toggle: Your logic would glitch and show undeterministic behaviour.
Same goes for the actual 'state' signal (this handles the synthesizer by one-hot encoding).
If your input signal violates timing constraints or glitches (like a push button bouncing), you'll be left with a lot of funky behaviour with a fully asynchronous approach, as (rare) metastability issues might get into the play. This is when you'll notice FPGA architecture differences, this is a 'yes' to question one.

Bottomline: You'll need to have some kind of sampling and debouncing/dead time circuit or another synchronization method to derive a clock-like event pulse from your physical encoder.
Question is if your encoder events can be faster than your sampling clock, else it's kinda trivial to sync in.

Then for the gated clock: Simply use your original clock and a 'clock enable' (the CE pin) within a conditional construct and the warning will go away. The reason for avoiding gated clock constructs is that clocks are routed on a dedicated network. When logical combinations (the gating) apply to the clock, it's routed back and forth between fabric and the network which causes arbitrary clock skew, each different every time you re-synthesize.

Async designs are only stable when there is no concurrency in events, I use them rarely in complex FSMs (2- or 3 process notations), although they eventually evaluate synchronously as well. And to make the latch warning go away, you'll have to explicitely set each driven signal in the process for each state case. So for second question: Yes, avoid.

[Berni]

Yep as others said combinational logic makes glitches during changes that can trigger async latches.

The way this is typically done is to clock your state machine from a internal clock that runs much faster than your encoder will go. This also allows you to implement some digital debounce circuitry to filter any short glitches out of the encoder signal (The mechanical encoders make lots of contact bounce glitches)

If you have some ultra high resolution encoder that produces 1 million pulses per revolution and need to process encoder signals that run at 100MHz then you might have to treat the encoder as a clock signal to a up/down counter in order to get it to run fast enough. Such an encoder would likely be optical moire type so it would produce a clean signal that is usable as a clock.

[SiliconWizard]

Asynchronous logic must be used with extra care  on FPGAs, which are designed and optimized for synchronous logic. Doesn't mean that you can't use it, but it can get pretty hairy, you better know what you're doing and know your tools well, and make sure you really need asynchronous...

With that said, there's usually no reason to use asynchronous state machines. You could post your code so we can suggest an equivalent synchronous approach.

[hal9001]

Thanks all for your explanation!! Synchronous is best practice then.

What happens to power use if instead of being asynchronous now a 100 MHz clock is used for the synchronous design? I guess because now the clock has to drive many more signals that the power increases v the undesired latched version?

If you have some ultra high resolution encoder that produces 1 million pulses per revolution and need to process encoder signals that run at 100MHz then you might have to treat the encoder as a clock signal to a up/down counter in order to get it to run fast enough. Such an encoder would likely be optical moire type so it would produce a clean signal that is usable as a clock.

Thanks this is appealing! Is this considered synchronous in this case? How can you clock on changes for 2 pins as each quadrature encoder requires 2 pins? Maybe xor the pins and drive the always block with that..

[Berni]

Thanks all for your explanation!! Synchronous is best practice then.

What happens to power use if instead of being asynchronous now a 100 MHz clock is used for the synchronous design? I guess because now the clock has to drive many more signals that the power increases v the undesired latched version?

Yes it would consume more power since the clocks are always running, but then again these clocks arrive trough the special clock distribution network where much less switching fabric is involved, so the increase is not the same as say running a counter at that speed.

Also since most encoders produce signals at most in the KHz region, it doesn't make sense to clock it at 100MHz, you can easily have a slow 1MHz clock for these things, at that point the dynamic power draw will be getting closer to the static leakage of the logic.

If you have some ultra high resolution encoder that produces 1 million pulses per revolution and need to process encoder signals that run at 100MHz then you might have to treat the encoder as a clock signal to a up/down counter in order to get it to run fast enough. Such an encoder would likely be optical moire type so it would produce a clean signal that is usable as a clock.

Thanks this is appealing! Is this considered synchronous in this case? How can you clock on changes for 2 pins as each quadrature encoder requires 2 pins? Maybe xor the pins and drive the always block with that..

This comes from the quadrature encoder trick using a up/down counter. You treat one quadrature signal as the clock for the counter while the other serves as a signal to tell the counter if to count up or down. So instead of labeling the inputs ENC_A and ENC_B they are actually more appropriately called STEP and DIRECTION. However this requires a nice clean signal, so it would not work well with noisy mechanical encoders, only with things like optical or hall sensor encoders. It also provides you with a parallel count result that is asynchronous, so you now need to synchronize an even wider bus into another clock domain to use it, but i suppose gray code counters could help with that.

There certainly are ways of using async designs in FPGAs, but you will have a easier time if you avoid them whenever there is a synchronous solution possible. The HDL compilers like working with those more, the FPGAs are designed for them and they are more reliable in general with less potential for weird funky metastability bugs.

[SiliconWizard]

What happens to power use if instead of being asynchronous now a 100 MHz clock is used for the synchronous design? I guess because now the clock has to drive many more signals that the power increases v the undesired latched version?

You're onto something, but on a typical FPGA, the answer is a bit more complex than this.
As already said above, since there are large clock distribution trees on FPGAs, and FFs have clock input that are not necessarily gated, even when all logic cells are not used, an increased clock freq will get you a significantly increased power consumption.

So a general thought would be to use a 100 MHz clock only if you really need that for the rest of your design. Otherwise, lower the clock frequency. If there's say an external 100 MHz oscillator on your board, no problem - FPGAs have internal clock dividers, and often PLLs, which can get you lower frequencies that'll be distributed inside the FPGA.

Now if you need different frequencies for different parts of your design, that's also possible.

A thought is that if you're after "low" power consumption, Spartan-6 and Artix-7 FPGAs are not the best candidates out there. But we'd need to know your requirements, what else does it need to do apart from this quadrature decoder?

[NorthGuy]

This comes from the quadrature encoder trick using a up/down counter. You treat one quadrature signal as the clock for the counter while the other serves as a signal to tell the counter if to count up or down. So instead of labeling the inputs ENC_A and ENC_B they are actually more appropriately called STEP and DIRECTION.

This will lose position at the direction change. For example, your STEP transitions from high to low, then the encoder stops and starts rotating back. Consequently, your STEP will transition back to high, you will increment or decrement the position, but in fact the position hasn't changed since the previous rising edge of the STEP.

[radar_macgyver]

It's a bit of a nit-pick, but it's the design tools that generally have a hard time with async logic since it's much harder to do reliable timing analysis. The hardware is able to do it just fine.

Some use-cases of async logic end up with very high fan-out on some nets (for example, a subsystem-wide async reset - a system level async reset will get mapped to the GSR global net). High fan-out async reset nets will increase your timing scores, and can cause weird effects like some FFs getting reset before others. Much better to use synchronous reset and let the timing tools guarantee that all resets happen on the same clock edge.

Finally, in cases where you really want gated clocks (for example, to control power dissipation), on Xilinx devices you can use a BUFGMUX and friends to turn off a clock to a section of the device. Maybe the newer Vivado tools can infer them but on ISE they must be instantiated manually.

[asmi]

As already said above, since there are large clock distribution trees on FPGAs, and FFs have clock input that are not necessarily gated, even when all logic cells are not used, an increased clock freq will get you a significantly increased power consumption.

1. Pretty much all synchronous blocks inside FPGAs I worked with have clock enable pin, which can be routed via clock backbone or regular fabric.
2. All unused logic cells are kept in a static state, with synchronous blocks don't have clock pin connected, and don't meaningfully contribute to power consumption, except for maybe super-small designs which consume very little dynamic power, and so static power becomes comparable. Some blocks when used (for example PLL) can consume quite a bit of power, which often surprises designers.

[Berni]

This comes from the quadrature encoder trick using a up/down counter. You treat one quadrature signal as the clock for the counter while the other serves as a signal to tell the counter if to count up or down. So instead of labeling the inputs ENC_A and ENC_B they are actually more appropriately called STEP and DIRECTION.

This will lose position at the direction change. For example, your STEP transitions from high to low, then the encoder stops and starts rotating back. Consequently, your STEP will transition back to high, you will increment or decrement the position, but in fact the position hasn't changed since the previous rising edge of the STEP.

Yep. This is the downside of that approach versus using a proper state machine to do it.

Again all depends on the requirements, some encoders make a full quadrature cycle on each detent, so its actually preferred that only one edge is counted as a step. Ask generic questions, get generic answers.

[gnuarm]

I want to make an asynchronous state machine based on how a pins change similar to quadrature encoding. Im using Spartan 6 and get the warning

Found 1-bit latch for signal . Latches may be generated from incomplete case or if statements.

And

Gated clock. Clock net is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop.

First question. If this design moves as is from Spartan 6 to Artix or another brand of FPGA, will it have problems?
Second question. Should latches and asynchronous design be avoided or is there ever a reason to use asynchronous designs?

Yes, async designs can respond to input changes faster if that is important.  By faster, I mean gate delays rather than clock cycle delays. 

The second error message above indicates FFs are being used in the code.  Async state machines don't use FFs as such.  They use logic in ways that equate to a latch.  Transitions have to be planned so they don't create glitches in the outputs when an input changes.  You also have no protection against multiple inputs changing at the same time which is pretty much assured will cause glitches.  But "at the same time" is relative to the logic delay times, so not so likely I suppose. 

It is not easy to implement async state machines in an FPGA, but if you use primitives to map to LUTs, you should be able to do it.  The Xilinx LUTs themselves are assured to not generate glitches on single input changes.  I don't know about other brands of FPGAs.

I had a class in college that covered async state machines.  I'm sure I still have that book somewhere.  I don't think I've ever designed an async state machine though.  I do recall a coworker using one once.  I think he used a chip that was designed for that.  It would have been some 40 years ago!