Original Redmine Comment
Author Name: Wesley Terpstra (@terpstra)
Original Date: 2017-05-18T19:14:25Z

I've tried to implement this myself, but I got lost in the various output forms that use an AstNode. It does not seem too hard to do for someone more familiar with the code base. The format parsing stuff in EmitC.visit just needs to be moved to VL_VALUEPLUSARGS_IW, where it almost already exists anyway.

Original Redmine Comment
Author Name: Wesley Terpstra (@terpstra)
Original Date: 2017-05-18T20:05:38Z

I've set up an issue in the rocketchip repository that links to this issue. chipsalliance/rocket-chip#752

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-05-19T02:43:57Z

Basically, yes, but lots of details involved, as this dates back to before Verilator had true string support.

Anyhow, fixed in git towards 3.903.

Original Redmine Comment
Author Name: Wesley Terpstra (@terpstra)
Original Date: 2017-05-19T03:28:18Z

Firstly, thanks a lot for taking a look into fixing this! I noticed that $value$plusargs is returning a 32-bit value and not a boolean.

I get this warning:
%Warning-WIDTH: /scratch/terpstra/federation/rocket-chip/vsrc/plusarg_reader.v:15: Logical Operator LOGNOT expects 1 bit on the LHS, but LHS's VALUEPLUSARGS generates 32 bits.

When compiling this line:
if (!$value$plusargs(FORMAT, myplus)) myplus = DEFAULT;

I can work around this easily, but it is behaviour that differs from the other tools I use.

Original Redmine Comment
Author Name: Wesley Terpstra (@terpstra)
Original Date: 2017-05-19T04:07:19Z

I've tried verilator commit 7fb2962... it does not seem to update myplus. I'm investigating, but something still seems a bit wrong.

Original Redmine Comment
Author Name: Wesley Terpstra (@terpstra)
Original Date: 2017-05-19T05:13:52Z

Ok. I've figured it out. The return value of $value$plusargs MUST be inspected, otherwise the call is optimized away to nothing. Presumably it should be marked as having side-effects, since it modifies it's second argument.

So there are two problems remaining:
1- Return result is 32-bit wide instead of 1-bit wide
2- The call is optimized away if the result is unused

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-05-19T11:20:52Z

The spec says it's an integer return, so the warning is technically correct, but silly. I committed to suppress it when comparing it as one bit.

The internal attributes to not optimize look correct, please modify the test_regress/t/t_sys_plusargs.v example as needed to show the other problem.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-05-31T02:06:46Z

In 3.904.