Latch inference in HDLs - Page 1
Forum section: electronics / general

author: rubenvann
author_rank: Newbie
timestamp: September 02, 2016, 11:47:25 am
content: I have a hopefully short question about latch inference. I am trying to prepare for a course in digital systems. I found this old exam question online:Code:proc2: process (x, y, z, sel) isbeginif (sel = “-0”) then -- het symbol “-“ representeert een don’t carew <= x xnor y; -- voor std_logic typesendif;v <= (x and y) and z;end process;The question is if this process will infer a latch or not. I thought it will; the output w needs to be remembered in case that sel(1) will change to 1 (because in that case, the if statement will not be executed, and w will not change; so w needs to 'remember' its old value. Is the provided answer wrong, or is my reasoning wrong?(the answer onhttp://electronics.stackexchange.com/questions/18075/how-to-avoid-latches-during-synthesisalso seems to imply that a latch would be inferred).Thanks in advance

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 02, 2016, 02:39:11 pm
content: A latch will be inferred for w for exactly the reasons you state. If you add an "else" clause to the "if" in your process block a latch will not be inferred.

author: rstofer
author_rank: Super Contributor
timestamp: September 02, 2016, 06:34:16 pm
content: You can also define a default output for 'w' by just putting w <= '0'; right after the 'begin'.Shorter answer: Every signal needs to be defined under all conditions. This becomes quite the bookkeeping chore in large FSAs with dozens out outputs. Every output must be defined under all conditions! So put a bunch of default assignments at the top of the process, right after 'begin'. Lots of them!Every time you create a new output in the FSA, the very next thing to do is add that default assignment. Troubleshooting unintended latches can be quite a challenge.

author: KE5FX
author_rank: Super Contributor
timestamp: September 02, 2016, 06:36:56 pm
content: Even shorter answer: let the synthesis tool worry about it.Most of your logic should be synchronous to one clock or another. Latches aren't a problem if you don't rely on combinational logic to do anything outside of the context of a clocked FSM.

author: rstofer
author_rank: Super Contributor
timestamp: September 03, 2016, 03:31:39 pm
content: My FSMs always have two processes: The next state process is clocked and consists of simply registering the next_state value into the current_state. The FSM logic itself is always combinatorial and if I'm not real careful, I will wind up with latches holding values in future states that are totally inappropriate.I guess the reason I do this is that the combinatorial logic may be kicking off some external process on the upcoming clock. If that start signal doesn't occur until after the next clock edge, the external process is one clock behind. That means, for example, that I can't test an external counter in the very next state because it won't be loaded until the next state.All of which can be coded around. But since it is easy to avoid latches by having default signal values, there is no reason to add the complication.

author: KE5FX
author_rank: Super Contributor
timestamp: September 04, 2016, 01:56:10 am
content: Quote from: rstofer on September 03, 2016, 03:31:39 pmSounds like a one-way ticket on a screaming plunging supersonic train to timing-closure hell.

author: nctnico
author_rank: Super Contributor
timestamp: September 04, 2016, 09:54:03 am
content: Quote from: rstofer on September 02, 2016, 06:34:16 pmWhat helps to prevent this is to always use synchronous logic (a process which only depends on a clock). I don't quite understand why you would want to put the FSM logic outside the FSM. If the cases get too big I'd use functions but certainly not seperate processes.

author: rstofer
author_rank: Super Contributor
timestamp: September 04, 2016, 03:52:45 pm
content: I looked into the subject of one versus two processes and the views are split. I don't know if it is 'even' but one of the Xilinx guys is recommending two:https://forums.xilinx.com/t5/Synthesis/Differences-between-one-process-and-two-process-FSM/td-p/214607But even there, opinions vary. I have the feeling that it doesn't make an iota of difference and is simply a 'blue versus green' kind of deal. In either case, all signals have to be defined at all times, nothing changes in that regard. Whether they are explicitly controlled by assignments in every state, have default values or are handled with 'else' or 'when others', they still have to be defined at all times.Here the two process approach is criticized as a FAIL when, in fact, latches would have been inferred either way. The OP didn't have control of all signals at all times:https://forums.xilinx.com/t5/Synthesis/problem-in-synthesis-of-stste-machine/m-p/135806I guess I'm looking for more compelling reasons than simply 'blue versus green' to change to a single process. Maybe I can find a tutorial or something. Or maybe gin up a small FSM using both techniques and compare the RTL schematics.

author: nctnico
author_rank: Super Contributor
timestamp: September 04, 2016, 04:04:55 pm
content: Quote from: rstofer on September 04, 2016, 03:52:45 pmNo, not really. In a (synchronous) clocked process a signal which isn't receiving a new value stays the same. Whether the design can live with a random startup value (even though it usually is zero in an FPGA) is up to the designer.

author: rstofer
author_rank: Super Contributor
timestamp: September 04, 2016, 06:50:02 pm
content: Quote from: nctnico on September 04, 2016, 04:04:55 pmWhich is usually the wrong thing! So, in state 14 I output a signal for one clock that causes something external to the FPGA to occur at the next clock edge. Very likely, I want that signal to go away when I get to the next state. Of course, this is the whole problem with inferring latches. The retained state is unlikely to be the one you want since it was only required for one clock period.

author: nctnico
author_rank: Super Contributor
timestamp: September 04, 2016, 06:55:32 pm
content: Quote from: rstofer on September 04, 2016, 06:50:02 pmIn that case make it go away in the next state. If not, leave it alone. The less you define the states of a signal the less logic a signal will depend on (more don't cares in the equation) and thus it will take less recources / will be easier to place & route by the synthesizer resulting in a higher possible clock rate. A small state machine is often encoded using the on-hot method so if a signal needs to go high in state A and low in state B then it will only depend on combining the output from 2 flipflops.

author: rstofer
author_rank: Super Contributor
timestamp: September 04, 2016, 07:55:50 pm
content: Quote from: nctnico on September 04, 2016, 06:55:32 pmAnd if there are multiple destination states (like the n-way instruction decode branch following the fetch cycle(s)), the signal has to be dealt with in each.I'm a huge fan of defining default values and getting it all done in one place. It's done, the signal always has a defined value and I don't need to think about it again.I have been caught quite a few times with inferred latches and debugging them is a PITA. It produces truly bizarre results. The good news is the synthesizer will often produce a warning. I wonder if I could escalate that to an error?

author: nctnico
author_rank: Super Contributor
timestamp: September 04, 2016, 08:03:03 pm
content: I'm still having the feeling you try to contort something out of shape which can be avoided by using different coding techniques.And I can imagine an inferred latch can produce the craziest results because in an FPGA the latch-enable signal is very likely to have glitches so the result can be completely random.

author: KE5FX
author_rank: Super Contributor
timestamp: September 05, 2016, 12:13:19 am
content: Quote from: rstofer on September 04, 2016, 07:55:50 pmWhy not define the defaults in the same FSM?Code:always @(posedge my_clock) beginfoo <= 1;bar <= 2;bat <= 3;case (my_state). . .SOME_STATE:bar <= 4;my_state <= SOME_OTHER_STATE;. . .SOME_OTHER_STATE:bar <= 5;bat <= 6;my_state <= YET_ANOTHER_STATE;. . .endcaseendKosher as Christmas. Bob's your uncle. Got 'er done.QuoteThat's a sign that your design approach needs reconsideration.

author: rstofer
author_rank: Super Contributor
timestamp: September 05, 2016, 01:11:20 am
content: Quote from: KE5FX on September 05, 2016, 12:13:19 amIn terms of default values, the approach is the same whether it is done in a clocked process or in the combinatorial portion of the FSM.In the early days, 10 years back or so, as I added code to my FSM for the CPU, I would create signals and forget to add the default assignment. Early times...

author: jonrc
author_rank: Newbie
timestamp: September 05, 2016, 01:15:29 pm
content: Yes you will most likely get an inferred latch on w and normally you do not want that in most FPGA/CPLDs designs for various reasons. One is that they tend to take up a lot of space, since most devices isn’t really made for latches.BRJon

author: hamster_nz
author_rank: Super Contributor
timestamp: September 05, 2016, 09:00:46 pm
content: "Never send a latch to do a flip-flop's job" - me