Width mismatch warnings #350
Comments
Original Redmine Comment True enough. By the verilog rules, the expression "32 - 1" has width 32, which is what verilator correctly reports. It's allowance of the width 5 is an attempt to reduce false warnings, but at the time the widths are resolved it can't know the expression will later resolve to a smaller width (because expression eval itself depends on width determination!) The best it can do for now is use the 5. Sorry |
Original Redmine Comment I know this is an old issue, but I recently encountered this same problem using Verilator to get my RTL lint clean, and I managed to find a simple work-around using a localparam:
Note that Verilator will treat NUM_M1 as having a width of either 32 or 5, so it is necessary to restrict the range to [4:0] when assigning to counter. |
Author Name: Amin Firoozshahian
Original Redmine Issue: 350 from https://www.veripool.org
It seems that when assigning constant expressions to a signal, Verilator expects the LSH to be as wide as the widest parameter on the RHS, rather than the result of the expression. For example, when compiling the following code:
gets the following warning:
%Warning-WIDTH: test.v:15: Operator ASSIGNDLY expects 5 bits on the Assign RHS, but Assign RHS's SUB generates 32 or 6 bits.
%Warning-WIDTH: Use "/* verilator lint_off WIDTH */" and lint_on around source to disable this message.
%Error: Exiting due to 1 warning(s)
%Error: Command Failed verilator_bin --cc test.v --top-module test
This is while `NUM-1 fits exactly in the 5 bits provided by the LHS signal.
The text was updated successfully, but these errors were encountered: