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

Mis-evaluation of typed parameter #606

Closed
veripoolbot opened this issue Jan 18, 2013 · 4 comments
Closed

Mis-evaluation of typed parameter #606

veripoolbot opened this issue Jan 18, 2013 · 4 comments
Assignees
Labels
resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


Author Name: Jeremy Bennett (@jeremybennett)
Original Redmine Issue: 606 from https://www.veripool.org
Original Date: 2013-01-18
Original Assignee: Wilson Snyder (@wsnyder)


The following code has a module parameterized with a typed localparam and triggers a compilation error.

module t (/*AUTOARG*/
    // Inputs
    clk
    );
    input clk;

  localparam logic[4:0] WID = 16;
  wire [15:0] b33;

  test #(WID) i_test_33(.clk (clk),
			.b   (b33));

endmodule

module test (/*AUTOARG*/
    //Inputs
    clk,
    // Outputs
    b
    );
    parameter  WIDTH = 10;
    localparam MSB   = WIDTH - 1;

    input               clk;
    output wire [MSB:0] b;

    wire [MSB:0]        a;
    assign b = {~a[MSB-1:0], clk};

endmodule

A number of warnings and errors follow, starting with:

%Warning-LITENDIAN: t/t_param_module.v:42: Little bit endian vector: MSB < LSB of bit range: -17:0

Verilator appears to mis-evaluate the localparam @width@ as -16 (rather than 16) when used in the test module to set the value of @msb@. The problem appears to be with using a typed localparam declaration. If this is replaced with

localparam WID = 16;

everything works fine. Looking at the code, I have so far traced to the problem to @visit(AstVarRef* nodep, AstNUser*)@ in @V3Const.cpp@. I'm working on a fix, but in the meantime, please pull a test case from branch param-module at git@github.com:jeremybennett/verilator.git

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Jeremy Bennett (@jeremybennett)
Original Date: 2013-01-18T16:20:15Z


OK - I'm homing in on the problem. Looks like Verilator treats logic as signed by default, whereas it should be unsigned (IEEE 1800-2009 section 6.9.1). So in a 5-bit parameter decimal 16 is actually decimal -16. Watch this space for the fix...

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-01-19T02:38:41Z


This is a fun case because the parent module has a 5 bit unsigned parameter, which type mismatches with the child's parameter. While that's very interesting it turns out to have nothing to do with the bug - it's simply that dtypeChgWidthSigned had a bool third parameter which should have been V3Numeric, this caused some unsigned numbers to become signed; I had to add several prints before I noticed as C++ simply did implied type conversion on it.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Jeremy Bennett (@jeremybennett)
Original Date: 2013-01-20T11:30:53Z


Hi Wilson,

Thanks for fixing this. I'm glad it wasn't too obvious - I was tearing my hair out trying to see what was going wrong.

Jeremy

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-02-05T03:22:16Z


In 3.845.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants