Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)

Inferred latch warning

Altera_Forum
Honored Contributor II
1,967 Views

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.
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
526 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
526 Views

 

--- 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. 

0 Kudos
Altera_Forum
Honored Contributor II
526 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
526 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
526 Views

 

--- 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.
0 Kudos
Reply