Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Width mismatch warnings #350

Closed
veripoolbot opened this issue May 12, 2011 · 2 comments
Closed

Width mismatch warnings #350

veripoolbot opened this issue May 12, 2011 · 2 comments

Comments

@veripoolbot
Copy link
Contributor

@veripoolbot veripoolbot commented May 12, 2011


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:


`define NUM  32

module test
  (output logic [4:0] counter,
    input  logic       clk,
    input  logic       rst);

    always_ff @(posedge clk) begin
       if (rst)
         counter <= `NUM - 1;
       else
         counter <= counter - 1;
    end
endmodule // test


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.

@veripoolbot
Copy link
Contributor Author

@veripoolbot veripoolbot commented May 12, 2011


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-05-12T17:18:49Z


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

@veripoolbot
Copy link
Contributor Author

@veripoolbot veripoolbot commented Nov 10, 2016


Original Redmine Comment
Author Name: Nathan Clarke
Original Date: 2016-11-10T08:14:59Z


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:

 localparam NUM_M1 = `NUM - 1;

 always_ff @(posedge clk) begin
     if (rst)
         counter <= NUM_M1[4:0];
     else
         counter <= counter - 1;
 end

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant