Forum Discussion

lusant's avatar
lusant
Icon for New Contributor rankNew Contributor
2 years ago
Solved

Quartus 20.1 and warnings about Latches

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...
Hdl
  • FvM's avatar
    FvM
    2 years ago

    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

ShengN_altera's avatar
ShengN_altera
Icon for Super Contributor rankSuper Contributor
2 years ago

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.