Quartus 20.1 and warnings about Latches

Hi,
the warning about latch inference is erronous. Latches can be only generated in combinational logic, not in an edge sensitive process that infers DFF.

Quartus produces this inappropriate warning apparently because five registers representing SpeedLimit are discarded in synthesis, staying at constant 0. You need to do nothing about this warning.

Line 99 is useless by the way. A register keeps its value without being reassigned.
SpeedLimit <= SpeedLimit;

Hi,

I found out that the reason for the latch being implemented are due to both the asynchronous reset and operations inside the if statement SpeedLimit <= SpeedLimit + 10000; / SpeedLimit <= SpeedLimit - 10000; The Racq1Pos_ proc and Racq2Pos_proc don't have the problem.

The SpeedLimit is updated conditionally inside a clocked process. If SWPulseOn0 is '1', it's incremented, and if SWPulseOn1 is '1', it's decremented. However, in situations where neither of these conditions is met, SpeedLimit is assigned its current value, which can lead to a latch being inferred if the reset operation is asynchronous.

Therefore, if want to use those operations inside the if statement, you have to use synchronous reset instead of asynchronous reset so that latch is not implemented for example below:

SpeedLimit_proc: process (clk, rst, SpeedLimit)

begin

if rising_edge(clk) then

if rst = '0' then

SpeedLimit <= 500000;

else

--SpeedLimit <= SpeedLimit;

if SWPulseOn0 = '1' then

if SpeedLimit < 900000 then

SpeedLimit <= SpeedLimit + 10000;

end if;

elsif SWPulseOn1 = '1' then

if SpeedLimit > 200000 then

SpeedLimit <= SpeedLimit - 10000;

end if;

end if;

end if;

end if;

end process;

RTL and simulation waveform screenshots are attached below for your reference.

Thanks,

Best Regards,

Sheng

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

Sorry, but your conclusions about synchronous reset aren't substantiated.

There are no latches generated in the posted design. That's just a fiction of Quartus synthesis tool. Review RTL and post-mapping netlist to verify.

You're getting latches because you put SpeedLimit in the sensitivity list and you have that SpeedLimit <= SpeedLimit; line. This implies that the process gets activated whenever the value of SpeedLimit changes. If none of the other conditions are true or have changed when this happens, the current value of SpeedLimit must be stored, and a separate latch gets used. Just try removing SpeedLimit from the sensitivity list.

Thank you all for your collaboration.

Let's see if I'm able to explain the tests I made after reading your hints, because this stuff is more dense than I expect:

First, using the hint of @FvM I change the code, eliminating the line with the sentence SpeedLim <= SpeedLim; and change one limit value for some value which is 2^n - 1 (all ones in the value), and the result was the following:

In this situation the warning appear again and the logic synthetized has in fact some latchs (at least combinatorial logic) around the SpeedLimit, we can see those in the Map Viewer, like this:

Next, I replace the increment of the signal SpeedLimit to some value which is also a power of 2 minus 1.

In this situation, all the warnings disappear and all the logic around SpeedLimit is edge triggered, see the following images:

In the Map Viewer I didn't found any combinational logic around SpeedLimt:

The first conclusion is that the Latchs stuff are dependent (at least) of the values that the variable takes, I mean, the use of the bits that represent the variable.

Next, related with the suggestion of @ShengN_Intel , I changed the process like you told, and the result is:

The warning disappear, but there are combinatorial logic around SpeedLimit. I don´t know if that logic has a chance to create Latchs problems or not:

I think there are no need to paste more pictures, anyway if I use the same change that I made in the test above, I mean, use a power of 2 minus 1 to increment the SpeedLimit, all the logic associated to this signal will be also edge triggered.

Second conclusion, the Sync or Assync use of reset has influence in the warnings related with the Latchs stuff. Anyway, there are som combinatorial logic around SpeedLimt signal (and is not the use of the signal, it is the generation of the signal itself, at least, this is my interpretation)

Related to the suggestion of @sstrell , the signal SpeedLimt was in the sensitivity list because my first change was to insert the useless statement SpeedLimit <= SpeedLimit inside the process, and when I did this, I got one warning related with the use of the signal inside the process and wasn't in the sensitivity list. In a curious way I can't repeat this.

So, for the future, I looks like Quartus has some reasons to give warnings, but not always in a clear way.

This stuff is completely new for me and I think that I need to learn to live with the warnings ...

Thanks again for your collaboration.