False(?) UNOPT warning in combinational generate loop operating on MDA #1342
Assignees
Labels
resolution: no fix needed
Closed; no fix required (not a bug)
Comments
|
Original Redmine Comment UNOPT is complaining because your "wire t" is inside the loop, and there is a dependency loop through this wire (ignoring hierarchy), so this warning is correct. If you move it outside the loop it becomes an UNOPTFLAT which is also correct. See the manual as to the performance implications of this - it's "just" a performance warning related to Verilator not fundamentally wrong code. |
veripoolbot
added
resolution: no fix needed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Author Name: Alex Reed
Original Redmine Issue: 1342 from https://www.veripool.org
Original Assignee: Wilson Snyder (@wsnyder)
The attached test-code generates @UNOPT@ warnings with Verilator 3.926. This is a distilled test-case that exposes a bug in another EDA tool. Defining @fail@ causes the other tool to fail to compile. The work-around (using a temporary/intermediate variable) is sufficient for the other EDA tool.
When the same test-case is run through Verilator, the original version (@fail@ defined) generates @UNOPT@ and @ALWCOMBORDER@ warnings. I believe that the @ALWCOMBORDER@ is synonymous with the bug in the other EDA tool. When the work-around version (@fail@ not defined) is parsed by Verilator, only an @UNOPT@ is generated.
Interestingly, the real code (that was distilled to this test-case) actually generates @UNOPTFLAT@ but as far as I can tell this appears to be a similar error.
The text was updated successfully, but these errors were encountered: