Latch inference in HDLs

[rubenvann]

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: [Select]

proc2: process (x, y, z, sel) is
begin
if (sel = “-0”) then -- het symbol “-“ representeert een don’t care
    w <= x xnor y; -- voor std_logic types
endif;
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 on http://electronics.stackexchange.com/questions/18075/how-to-avoid-latches-during-synthesis also seems to imply that a latch would be inferred).

Thanks in advance

[Sal Ammoniac]

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.

[rstofer]

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.

[KE5FX]

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.

[rstofer]

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.

[KE5FX]

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.

Sounds like a one-way ticket on a screaming plunging supersonic train to timing-closure hell. 

[nctnico]

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.

What 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.

[rstofer]

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/214607

But 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/135806

I 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.

[nctnico]

  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.

No, 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.

[rstofer]

  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.

No, not really. In a (synchronous) clocked process a signal which isn't receiving a new value stays the same.

Which 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.

[nctnico]

  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.

No, not really. In a (synchronous) clocked process a signal which isn't receiving a new value stays the same.

Which 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.

In 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.

[rstofer]

  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.

No, not really. In a (synchronous) clocked process a signal which isn't receiving a new value stays the same.

Which 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.

In that case make it go away in the next state.

And 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?

[nctnico]

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.

[KE5FX]

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.

Why not define the defaults in the same FSM?

Code: [Select]

always @(posedge my_clock) begin

   foo <= 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;
      . . .
   endcase
end
Kosher as Christmas.  Bob's your uncle.  Got 'er done.

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?

That's a sign that your design approach needs reconsideration.

[rstofer]

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.

Why not define the defaults in the same FSM?

Code: [Select]

always @(posedge my_clock) begin

   foo <= 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;
      . . .
   endcase
end
Kosher as Christmas.  Bob's your uncle.  Got 'er done.

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?

That's a sign that your design approach needs reconsideration.

In 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...

[jonrc]

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.
BR
Jon

[hamster_nz]

"Never send a latch to do a flip-flop's job" - me