Forum: FPGA, VHDL & Verilog Discouraged use of latches in CPLD/FPGA logic

 Author: Element G. (Company: Matrix Switch Corporation) (elementgreen) Posted on: 2015-04-23 00:18

Rate this post
 0 ▲ useful ▼ not useful
Hello,

I've looked around quite a bit for information on the discouraged use of
latches in CPLD/FPGA logic, but am still having trouble wrapping my head
around the issues.  So I was hoping someone on this forum could help me
get a clue.

I created a very simple Verilog module (for a Xilinx XC9500XL series
CPLD) which is meant to handle input from 4 active low push buttons
which select from 4 inputs and display the current selection on LEDs
behind the buttons.

Here is the code:

module Main (
input [3:0] Buttons,
output [3:0] Leds
);

reg [1:0] CurInput;

initial begin
CurInput = 0;
end

assign Leds = 4'b0001 << CurInput;

always @ (Buttons)
begin
if (Buttons[0] == 0) CurInput = 0;
else if (Buttons[1] == 0) CurInput = 1;
else if (Buttons[2] == 0) CurInput = 2;
else if (Buttons[3] == 0) CurInput = 3;
end

endmodule

Simple enough. The inferred latch occurs with the 2 bit CurInput
register.  I can understand why they end up being latches, since there
is no default else statement in the always block, and there is no clock
source.  So instead of flip-flops, they becomes latches, with all of the
apparent vileness those entail.

First question is, would this particular use of a latch actually be
problematic?  It seems like it would be fairly predictable to me, if any
button lines change, process the if statements, only one of which (or
none of which) will be executed, assigning a new value to CurInput or
leaving it at its previous value.  Maybe the issue is the other code
which depends on the value of CurInput not being synchronous?

Second question is if there is a way to handle this situation in a
better way without adding an oscillator to the design (it's a very cost
conscious application).  For example, are there any special primitives
which could be used or perhaps only updating logic depending on CurInput
when it changes?

If anyone has some pointers to solutions for very low cost oscillators,
that would also be helpful.  For these types of applications, it
probably doesn't need to be all that accurate.

Thanks for any thoughtful input on this.

Cheers!

Element

 Author: Lothar M. (lkmiller) (Moderator) Posted on: 2015-04-23 00:25

Rate this post
 0 ▲ useful ▼ not useful
Element Green wrote:
> First question is, would this particular use of a latch actually be
> problematic?
No, because here its very clear what generates and happens with the
latch. Usually latches occur accidentally and often triggered by
combinational circuit which tend to glitches. And a glitch is a no-go
for a latch...

 Author: Element G. (Company: Matrix Switch Corporation) (elementgreen) Posted on: 2015-04-23 01:35

Rate this post
 0 ▲ useful ▼ not useful
Lothar Miller wrote:
> Element Green wrote:
>> First question is, would this particular use of a latch actually be
>> problematic?
> No, because here its very clear what generates and happens with the
> latch. Usually latches occur accidentally and often triggered by
> combinational circuit which tend to glitches. And a glitch is a no-go
> for a latch...

Thank you for the input.

One thought occurred to me after I posted this. Since CurInput is a 2
bit value, could there be issues with the 2 bits not being updated
atomically, in regards to logic which is dependent on the value of
CurInput.  For this application, it would probably never matter, since
all it is doing is displaying the value to LEDs, so the human eye would
never see a very fast LED glitch (say for example if the input changed
in a manner which caused both bits to change).  But I'm starting to see
how it could be a problem if there was more critical asynchronous logic
downstream from CurInput (control of an external mux for example).  Does
that line of thinking make sense or are these bits indeed atomic
(synchronous) with dependent logic?

I can see how even in fairly simple scenarios an oscillator is a very
good thing to have.  I don't really see how else delays can be performed
in a predictable manner.  For example if the buttons controlled multiple
muxes and it was desirable to do a "break-before-make" switch, so that
multiple muxes were not both driving the same bus. It would have to
switch all muxes off, delay, and then switch on the active mux.  My
understanding is that an oscillator should be used in that case.

Element

 Author: Lothar M. (lkmiller) (Moderator) Posted on: 2015-04-23 07:59

Rate this post
 0 ▲ useful ▼ not useful
Element Green wrote:
> Since CurInput is a 2 bit value, could there be issues with the 2 bits
> not being updated atomically
Indeed, each of those two memory-elements ist updated independentliy
from the other. So if CurInput is 0 and theres a short spike on the
button[3] line, then maybe only one of the latches goes to the desired
'1'. And the result is a wrong state on CurInput.

> I don't really see how else delays can be performed
You're right: an oscillator together with a state machine (a counter is
the most simple kind of a FSM) is the only way to generate accurate
and reproducable delays of any kind.

 Author: Element G. (Company: Matrix Switch Corporation) (elementgreen) Posted on: 2015-04-23 16:02

Rate this post
 0 ▲ useful ▼ not useful
Thank you kindly for the helpful information.  I have a much better
grasp on the concepts now.

Cheers!

Element.

 Author: Verilogi (Guest) Posted on: 2015-04-30 10:56

Rate this post
 0 ▲ useful ▼ not useful
please distinguish synchronous and asynchronous latches

synch latches are of no problem

• $formula (LaTeX syntax)$