Quartus 20.1 and warnings about Latches

[lusant]

Hi, 
I'm starting with VHDL and I read that we should avoid Latches  when we can.
One way to generate those Latchs is to left open assignments in a process, normally when using IFs clauses.
In the image bellow I got the warning for the SpeedLimit_proc and I don't understand why.

At the same time, the Racq1Pos_ proc and Racq2Pos_proc, in the image bellow, don't gave any warning:

What I'm doing wrong ?

What should I do to avoid those warnings ?

[FvM]

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;

[ShengN_Intel]

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.

[FvM]

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.

[sstrell]

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.

[lusant]

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.

[FvM · Accepted solution]

Hi,

still some misunderstandings in your latest post.

First point, you don't need to worry about possible latch generation in clocked processes, neither about additional sensitivity list entries. 

The LEs you have marked in technology map viewer are not part of combinational pathes. All logic pathes start and end at a DFF (or an IO pin).

The key observation is that bits SpeedLimit(4 downto 0) which are claimed as latches by Quartus don't exist in the design at all. The respective output bits are tied to ground. This happens because SpeedLimit is varied in steps of 100000, which can be factorized as 2^5*5^5. Factor 2^5 corresponds to 5 LSB staying zero. Changing the limits (your first experiment) allows more steps but keeps step size 100000.

If you change one step to e.g. 100001, register bits SpeedLimit(4 downto 0) are implemented and the latch warning disappears.

It has been also suggested to change the reset to synchronous to remove the warning, I already rated the suggestion as inappropriate.
Why?
1. It's unnecessary. It masks an erroneous warning but doesn't solve a real issue.
2. It increases resource utilization, e.g. 27 to 35 LE with Cyclone 10 LP implementation. Asynchronous reset is already implemented in registers and "free" in terms of logic resources if you use a global reset signal, synchronous reset need additional logic.
3. It may have other unwanted effects, depending on the reset scheme of your application.

As stated, the warning is erroneous and should be corrected by Intel. For the time being, you can disable the warning by a synthesis directive in front of the architecture declaration

-- altera message_off 10631
-- altera message_off 10041

Best regards
Frank

[lusant]

@FvM , my conclusion is that your statements match with all of my tests .. anyway I have a lot to learn before see the complete picture.
I've started with VHDL last month, so, it is to early to understand all implications of Latch generation, Quartus bugs and a lot of different views under this kind of tools.
I'm learning .. and this is good.

Thanks again for your hints.

Luís