Forum Discussion
New ContributorQuartus 20.1 and warnings about Latches
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
Super ContributorHi,
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.
