Community
cancel
Showing results for 
Search instead for 
Did you mean: 
EPeet
Beginner
936 Views

Quartus Prime: Inferring latch(es) for clocked process

I have a normal process with async reset and clock like below:

 

request_pulse   : in std_logic; 

 

signal pulse_in_d     : std_logic;

signal request_int    : std_logic;

signal flop_d       : std_logic;

 

p_dest_clk : process(dest_clk, dest_resetn)

  variable v_pulse_in_mxd : std_logic;

begin

if dest_resetn = '0' then

   pulse_in_d     <= '0';

request_int    <= '0';

elsif rising_edge(dest_clk) then

    if generic1 then  

      pulse_in_d    <= request_pulse;

      v_pulse_in_mxd  := request_pulse and not pulse_in_d;

    else

      v_pulse_in_mxd  := request_pulse;

    end if;

 

    if generic2 then

      if generic3 then 

       request_int <= v_pulse_in_mxd xor request_int; 

      else

       request_int <= not flop_d;

      end if;      

    else

      request_int <= '0';

    end if;

   end if;

  end process p_dest_clk;

 

Generic1 and generic3 are set to false, generic2 is true. As the whole process is sequential, I don't understand why I get the following warning:

 

Warning (10631): VHDL Process Statement warning at gen_resync_data_receive.m.vhd(79): inferring latch(es) for signal or variable "pulse_in_d", which holds its previous value in one or more paths through the process.

 

0 Kudos
2 Replies
EPeet
Beginner
66 Views

Interesting.

When I simply replaced the generics (set either to true or false) by input ports (tied either to '1' or '0'), the warnings about the latches are gone.

Seems to me like a tool bug...

Tricky
New Contributor II
66 Views

As this is a code snippet, and doesnt reflect the real code, we can only guess as to what the problem is.

But in your conditions, Pulse_in_D is only assigned a value during reset, and cannot be assigned any values when reset = '1', hence you've made a latch with reset='0' as the enable.

Reply