Navigation Menu

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

Error on unsized literal constants: Too many digits for 32 bit number #1397

Closed
veripoolbot opened this issue Feb 6, 2019 · 3 comments
Closed
Labels
resolution: no fix needed Closed; no fix required (not a bug) type: feature-IEEE Request to add new feature, described in IEEE 1800

Comments

@veripoolbot
Copy link
Contributor


Author Name: Greg Taylor
Original Redmine Issue: 1397 from https://www.veripool.org


Verilator throws an error on unsized literal constants larger than 32-bits, e.g. 'hFFFFFFFFFFFFFFFF.

I cannot find in IEEE Std 1800-2017 where there is an artificial cap of 32-bits. On page 73 there is some language regarding it, but it simply states the number will be at least 32-bits:

"The number of bits that make up an unsized number (which is a simple decimal number or a number with a base specifier but no size specification) shall be at least 32. Unsized unsigned literal constants where the high-order bit is unknown (X or x) or three-state (Z or z) shall be extended to the size of the expression containing the literal constant.

NOTE—In IEEE Std 1364-1995, in unsized literal constants where the high-order bit is unknown or three-state, the x or z was only extended to 32 bits."

I'm using Verilator 4.010.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-02-06T11:46:36Z


If Verilator did not complain on this, and you moved to a different simulator with the 32-bit restriction, your code would break. That is bad.

Just add the size to the number and you'll have properly portable code.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Greg Taylor
Original Date: 2019-02-06T12:33:18Z


Does this fundamentally break the simulation?

I came from Modelsim which doesn't complain about this and simulates with no issues.

Portability to other simulators and their shortcomings is less of a concern to me. Arbitrarily hardcoding the bitwidth can introduce errors (silently truncating the value), and that is a worse situation in my mind. I'd rather the tool figure out the correct bitwidth based on the value itself which is what the spec seems to imply.

If the error can be demoted to a warning, I could turn it off.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-02-07T00:49:21Z


I came from Modelsim which doesn't complain about this and simulates with no issues.

IMO that it doesn't warn about this is a Modelsim bug, but Modelsim doesn't have good lint in general which IMO is also a Modelsim bug ;)

Arbitrarily hardcoding the bitwidth can introduce errors (silently truncating the value)

Verilator and any half-good lint tool will warn if you do that.

I'd rather the tool figure out the correct bitwidth based on the value itself which is what the spec seems to imply.

No, it clearly says what Verilator does is compliant. It also says doing something else (extending) like Modelsim is compliant, provided it's in SystemVerilog and not traditional Verilog mode. Hence your results depend on what the simulator implementer decided and what version of the language is being parsed.

In general bit widths don't work the way people expect. The only way to get "intuitive" results is to size all numbers, even those < 32 bits.

If the error can be demoted to a warning, I could turn it off.

If you want to contribute a patch including tests to improve that, I'll take it. While technically it's an error and not a warning in Verilog (non SV), I'm ok just having it always suppressible.

@veripoolbot veripoolbot added resolution: nofixneeded type: feature-IEEE Request to add new feature, described in IEEE 1800 resolution: no fix needed Closed; no fix required (not a bug) and removed resolution: nofixneeded labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: no fix needed Closed; no fix required (not a bug) type: feature-IEEE Request to add new feature, described in IEEE 1800
Projects
None yet
Development

No branches or pull requests

1 participant