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

Detect data type and rvalue width mismatches #2231

Open
benjamin051000 opened this issue Aug 5, 2024 · 0 comments
Open

Detect data type and rvalue width mismatches #2231

benjamin051000 opened this issue Aug 5, 2024 · 0 comments
Labels
enhancement New feature or request style-linter Verilog style-linter issues

Comments

@benjamin051000
Copy link

benjamin051000 commented Aug 5, 2024

Summary

I'd like the ability to detect when an assignment has differing widths, and a warning that comes with it.

Test cases and examples
In the below example, address silently resolves to a value of 0 in QuestaSim.

localparam logic address = 32'hfffc; // BUG 'logic' does not match rvalue width of 32!

In the below example, sixteen is silently extended (I'm not sure if it's signed/arithmetic extension, either).

initial begin
    logic [31:0] thirtytwo = 32'habcdef;
    logic [15:0] sixteen = 16'hffff;

    // WARNING: (signed?) extension implicitly performed on `sixteen`
    if (thirtytwo == sixteen) begin
        // ...
    end
end

Proposal

Create a warning that checks for these width mismatches. Explicitly matching the widths via tools like WIDTH'(expression) can resolve the warning.

Additional Context
Even though this is a well-documented "feature" of (system)verilog, it can hide nasty bugs. In this case, explicit is better than implicit!

@benjamin051000 benjamin051000 added enhancement New feature or request style-linter Verilog style-linter issues labels Aug 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request style-linter Verilog style-linter issues
Projects
None yet
Development

No branches or pull requests

1 participant