Bump to Verilator 4.028.

[richardxia]

Related issue: #2370

Type of change: other enhancement

Impact: no functional change

Development Phase: implementation

Release Notes

I have given up on trying to switch to SiFive's (my) prebuilt Verilator binaries in #2370, but this at least bumps the compiled-from-source Verilator from 4.008 to 4.028, which represents about a year's worth of updates.

[aswaterman]

Sorry the binary dist approach didn't work out.

Both aspects of the CI flow (the Travis magic and the rocket-chip Makefiles) are impenetrable to me. It would be nice to clean all that up, but it's quite the project...

[richardxia]

Thanks, and no problem. I think we can address the Travis magic part at least by trying out a different CI provider. We've had success in other SiFive repositories using GitHub's own GitHub Action, and I at least find their configuration format to be less "magic" since there are fewer special-cases, even if it is a bit more verbose to type out.

[richardxia]

This is failing due to several instances of the following error:

%Error: /home/travis/build/chipsalliance/rocket-chip/emulator/generated-src/freechips.rocketchip.unittest.TLSimpleUnitTestConfig.v:69422: Unsupported: Width of number exceeds implementation limit: 65539'h0  (IEEE 1800-2017 6.9.1)
  assign _GEN_18 = _T_641 ? _T_649 : 65539'h0;  
                                     ^~~~~~~~

This was actually reported in verilator/verilator#2082 and fixed in verilator/verilator#2128, which made it into 4.028. That PR fix bumped the default max width from 5120 to 65536. I suppose there are two ways of fixing this: either 1) use the new --max-num-width command-line option to set some higher limit, or 2) actually fix whatever is generating this 64K-wide wire to generate something narrower.

@mikeyangsiv, did you run into anything like this when you were trying out the fix in verilator/verilator#2128 ?

[aswaterman]

I do not view these wide signals as erroneous, and still question the wisdom of making them errors by default in Verilator. I have no problem with setting --max-num-width=1048576 or something.

[mikeyangsiv]

@mikeyangsiv, did you run into anything like this when you were trying out the fix in verilator/verilator#2128 ?

No, I did not run into any further issues after they bumped up the default width in 4.028.

[mikeyangsiv]

I don't know of you looked up the spec flagged in the error, it says ...

IEEE 1800-2017 6.9.1

Implementations may set a limit on the maximum length of a vector, but the limit shall be at least
65536 (216) bits.
Implementations are not required to detect overflow of integer operations.

Note that in this specific case, integer literals can be written as unsized. ('h0 or '0). IEEE 1800-2017 5.7.1

[aswaterman]

I knew the spec explicitly permitted implementations to limit some of these parameters, but wasn't aware it specified lower bounds. Incidentally, C does the same thing, but normal users of C blow past the lower bounds in the spec all the time, because normal implementations of C don't impose such draconian limits.

Regardless, using the command-line option to increase the limit is the pragmatic choice for the time being.

[richardxia]

Thanks, I've pushed up another commit (aca2ac7) that sets --max-num-width to 1048576. I didn't run the full set of unit tests, but I did confirm that one of the compilations passed locally after I added this flag.