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

Missing width warning when part of a bus is compared #533

Closed
veripoolbot opened this issue Jul 20, 2012 · 5 comments
Closed

Missing width warning when part of a bus is compared #533

veripoolbot opened this issue Jul 20, 2012 · 5 comments
Labels
area: data-types Issue involves data-types area: lint Issue involves SystemVerilog lint checking effort: days Expect this issue to require roughly days of invested effort to resolve resolution: wontfix Closed; work won't continue on an issue or pull request

Comments

@veripoolbot
Copy link
Contributor


Author Name: Chandan Egbert
Original Redmine Issue: 533 from https://www.veripool.org
Original Date: 2012-07-20


Verilator generates incorrect code for the comparison

~a[m:0] == 0

where the total width of "a" is larger than m. The comparison in the following example

module select_invert(input logic clk, input logic [15:0] a);
     always @(posedge clk) begin
         if ((~a[5:0] == 0) == 0) begin
             $write("[%0t] %%Error: t_select_invert: failed\n", $time);
             $stop;
         end
     end
endmodule

should produce the value 1 when a is 0xffff. However, it produces the value 0.

An example in the verilator test_regress style is attached.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-07-20T10:29:03Z


Thanks for the good test, however I'm not sure why you think the answer should be 1, as VCS, NC and Verilator all agree the answer is 0.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Chandan Egbert
Original Date: 2012-07-20T14:56:43Z


If a = 16'hffff, a[5:0] would be 6'h3f. Inverting this should give 0. comparing this with 0 should give TRUE. However I get FALSE. Looking at the generated C code, I see that the verilog expression

~a[5:0] == 0

which should evaluate to TRUE

has been translated into

(0 == (~ (0x3f & (IData)(vlTOPp->v__DOT__val))))

which evaluates to FALSE.

Am I missing something here?

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-07-20T15:17:10Z


0 is 32 bits wide, not 6 bits. If you compare with 6'h0 you'll get what you expect.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-07-20T15:23:30Z


Actually there should be a WIDTH warning here to tell people what's odd.

Note also your test needs to compare only when a==40'h7fffffff as otherwise there's a time 0 race.

@veripoolbot veripoolbot added area: data-types Issue involves data-types area: lint Issue involves SystemVerilog lint checking effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-non-IEEE Request to add new feature, outside IEEE 1800 labels Dec 22, 2019
@wsnyder wsnyder added resolution: wontfix Closed; work won't continue on an issue or pull request and removed type: feature-non-IEEE Request to add new feature, outside IEEE 1800 labels Oct 16, 2022
@wsnyder
Copy link
Member

wsnyder commented Oct 16, 2022

Closing due to age, it's unlikely this warning will get improved and it's hard to avoid false warnings as "0" is often assumed to be any width by users.

@wsnyder wsnyder closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: data-types Issue involves data-types area: lint Issue involves SystemVerilog lint checking effort: days Expect this issue to require roughly days of invested effort to resolve resolution: wontfix Closed; work won't continue on an issue or pull request
Projects
None yet
Development

No branches or pull requests

2 participants