EmbDev.net

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


Author: Element Green (Company: Matrix Switch Corporation) (elementgreen)
Posted on:

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 Miller (lkmiller) (Moderator)
Posted on:

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 Green (Company: Matrix Switch Corporation) (elementgreen)
Posted on:

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 Miller (lkmiller) (Moderator)
Posted on:

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 Green (Company: Matrix Switch Corporation) (elementgreen)
Posted on:

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:

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

synch latches are of no problem

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [vhdl]VHDL code[/vhdl]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.