- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page