Skip to content

Conversation

@qmn
Copy link
Contributor

@qmn qmn commented Apr 16, 2025

LRM 6.9.1 says vectors (constant literals) may not exceed an implementation-defined width, which Verilator defaults to 2^16. While Verilator's internal limit can be overridden with --max-num-width, this PR nevertheless expands overly wide vectors into a concatenation of narrower vectors. Addresses #26883.

LRM 6.9.1 says vectors (constant literals) may not exceed an
implementation-defined width, which Verilator defaults to 2^16.
Expand overly wide vectors into a concatenation of narrower
vectors. Addresses lowRISC#26883.

Signed-off-by: Quan Nguyen <[email protected]>
Copy link
Contributor

@rswarbrick rswarbrick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a really good way to do things! I'd suggest a couple of slight tweaks:

  1. Change the commit message to mention the fact that the implementation-defined width is guaranteed to be at least 2^16 (which is why this change is guaranteed to work).
  2. Drop the max_width argument from expand_literal: I doubt we'll ever want a different value.
  3. Remove the outer cast from the result: we're already adding zeros to the MSB to ensure the width is correct anyway.

@alees24
Copy link
Contributor

alees24 commented May 4, 2025

Full investigation into the maximum literal/bit-vector widths added as a comment to #27069 where two alternative approaches are under discussion. I shall not replicate it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants