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
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...
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
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.
Thank you kindly for the helpful information. I have a much better grasp on the concepts now. Cheers! Element.
please distinguish synchronous and asynchronous latches synch latches are of no problem
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.