Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

Inferred latch warning

Hi,

When I write the following code:

ENTITY test IS

GENERIC (

DW: INTEGER := 4

);

... clk, rst_n and other ports

END ENTITY;

ARCHITECTURE rtl OF test IS

a: UNSIGNED(31 DOWNTO 0);

BEGIN -- arch

PROCESS (clk, rst_n)

BEGIN

IF rst_n='0' THEN

a <= TO_UNSIGNED(0, a'LENGTH);

ELSIF clk'EVENT AND clk = '1' THEN

a <= a + DW;

END IF;

... other code using a (this is the wrong place to do that, as was pointed out in the discussion)

END PROCESS;

... other code (incl. processes) that use a

END ARCHITECTURE;

When DW is e.g. 2 or 4 (but not 1), the compiler warns (10631) about latches being inferred for a. The warning seems incorrect to me: it is true that a(0) will not be assigned in the synthesized design, but only because the compiler has optimized away my assignment to it. And in effect, it becomes stuck to '0' and won't become a latch, as is expected.

This kind of warning is a nuisance in modular code since the warning is usually indicative of a serious design error, but it is false, and draws my attention away. Sooner or later I look over a genuine warning...

Can I avoid it somehow ?

Thanks,

J.

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Is it not because you have an asynchronous reset for a? this means the register is removed but it still has a reset assignment - hence a transparent latch.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    Is it not because you have an asynchronous reset for a? this means the register is removed but it still has a reset assignment - hence a transparent latch.

    --- Quote End ---

    You are right. But maybe I wasn't clear enough: there are NO latches inferred here, but the warning is issued nonetheless.

    I see no easy way of telling the compiler that it should not reset the bits for which it eventually optimizes away the registers. In the meantime, I tried several things:

    • use an (OTHERS => '0') initialization on a does not work;

    • dropping the IF rst_n ='0' clause altogether works, but doesn't seem such a good idea;

    • creating and using a synchronous reset signal does not work;

    • dropping the IF rst_n ='0' and using the synchronous reset in the clocked process section works, but a MUX is inferred and the zero a lines become registers again.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Is the warning more a false warning? is the latch actually removed later during synthesis. Might be better off raising a case with altera mysupport to find out exactly why it does this.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I only just noticed this:

    --- Quote Start ---

    ... other code using a

    --- Quote End ---

    Why have you got code outside the of the clocked region at all? this is NOT a recommended coding style, and is likely to produce simulation/hardware missmatches.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    I only just noticed this:

    Why have you got code outside the of the clocked region at all? this is NOT a recommended coding style, and is likely to produce simulation/hardware missmatches.

    --- Quote End ---

    Sorry, misplaced it during examplifying. Should have been outside the process.