CODEWITHSUNDEEP
vhdlsynthesiscircuit
Einheri
Einheri

Reputation: 985

During synthesis, should I care about the "found latch" warnings if I actually want the latches?

say I have the following state machine:

....
if state_a then
    output_a <= '0';
    next_state <= state_b;
elsif state_b then
    output_a < '0';
    if cond then
        output_b <= '1';
        next_state <= state_a;
    else
        next_state <= state_b;
    end if;
 end if;
 ......

I don't want output_b to change except when being assigned again in state_b. However, when I try to synthesise this code, most synthesis tools will say something along this line:

warning: found 1-bit latch for signal "output_b". latches aren't recommended for FPGA design because it might result in timing problems.

Should I worry about this at all? If so, why and what are the alternatives?

Upvotes: 0

Views: 265

Answers (3)

vleo
vleo

Reputation: 351

The problem you have stems from the FSM coding style you're (presumably) using. As other pointed it is not possible to guess what you want the code to do, since you did not provide enough code to figure that out, so I present one possible interpretation, assuming you really wanted to change output_a somehow and that one time (after reset) latching of output_b should happen at the same time FSM state transitions.

Using 2 processes per FSM style, we have code that is not giving latch warnings:

----
signal CLK, RESET, cond : std_logic;
type state_t  is (a,b);
signal state, state_next : state_t;
signal ouput_a, output_b, output_b_next : std_logic;
----
  FSM_clock: process(all)
  begin
    if rising_edge(CLK) then
      if RESET then
         state <= a;
         output_b <= '0';
      else
        state <= state_next;
        output_b <= output_b_next;
      end if;
    end if;
  end process;

  FSM_next: process(all)
  begin
    state_next <= state;
    output_b_next <= output_b;
    output_a <= '0';
    case state is
      when a => 
        state_next <= b;
      when b => 
        output_a <= '1';
        if cond then
          output_b_next <= '1';
          state_next <= a;
        else
          state_next <= b;
        end if;
    end case;
  end process;

Upvotes: 0

Ilya Kalistru
Ilya Kalistru

Reputation: 11

if you have incomplete if/elsif or case statement in a clocked process, it's absolutely harmless. 

if rising_edge(clk)
    if a then
        out <= b;
    end if;
end if;

It means that you have flip-flop with some sort of feedback, or, like in this case, you have flip-flop with clock enable pin used, which is even better.

If you have incomplete if/elsif or case statement in not clocked process - it's a latch and it's in most cases:

  1. something you don't really want;
  2. something that point out on a poor design and can be avoided with redesign.

If you complete your little example, someone can help you redesign it. Now it is not enough information.

Upvotes: 1

Qiu
Qiu

Reputation: 5751

Following Xilinx:

If latch inference is intended, you can safely ignore this message. However, some inefficient coding styles can lead to accidental latch inference. You should analyse your code to see if this result is intended.

Some techniques to avoid latch inference:

  • Make sure any "if / else if" statements have a concluding "else" clause,
  • Assign to all the same outputs in each case,
  • Include all possible cases in the case statement (but be aware that WHEN OTHERS clause always works, but can create extraneous logic).

Upvotes: 1

Related Questions