Support enumerated values in ilang, output to VCD files

[RobertBaruch]

Proposal:

It would be nice to support enumerated values in ilang, and then be able to see those values in VCD files, similar to how nMigen simulates and then outputs string values to vcd.

Example output from nMigen. Here, the op signal is an enumerated signal, so it has type string.

$comment Generated by nMigen $end
$date 2019-12-23 09:39:25.249074 $end
$timescale 100 ps $end
$scope module top $end
$var wire 8 0 x $end
$var wire 8 1 y $end
$var string 1 2 op $end
$scope module adder $end
$var wire 8 3 out $end
$upscope $end
$upscope $end
$enddefinitions $end
#0
$dumpvars
b0 0
b0 1
sADD/1 2
b0 3
$end
#10000
b11111111 1
b11111111 0
b11111110 3
#20000
b0 0
sSUB/0 2
b1 3
#30000

This could be accomodated by adding attributes to such enumerated signals, e.g.:

  attribute \enum_1_0 "SUB"
  attribute \enum_1_1 "ADD"
  attribute \src "adder.py:21"
  wire width 1 \op

where the format is \enum_<width>_<bits>. Here, SUB would be equivalent to 1'0 and ADD to 1'1.

Then, whenever yosys writes a VCD file including that signal, it would use $var string for the signal, attempt to match any value for that signal against \enum_<width>_<bits>, and if present, write s<attr-string>/<value> for the value of the signal, e.g. sADD/1. If the value of the signal does not have such an attribute, then the string value of the signal is the numeric value, s<value>, e.g. s1.

It wouldn't be necessary at this point to support Verilog enums. Presumably once enumerated values are supported in ilang it would maybe be part of the way to supporting Verilog enums.

[whitequark]

I believe this proposal has been implemented as a part of #1642.

[whitequark]

@RobertBaruch Could you explain why you suggested the following format?

where the format is \enum_<width>_<bits>.

To me it seems like <width> is extraneous but I must be missing something.

[RobertBaruch]

To support not having to add leading zeros, as in 16'0.

[whitequark]

When is not having leading zeroes important? The current representation is harder to work with in whatever backend ends up interpreting the enumeration, is that justified?

[RobertBaruch]

I have no opinion either way. It was just based on my own usage in Verilog, but if it's automatically generated, it makes no difference.

[whitequark]

Thanks for the explanation. If you are not opposed to it, I would much prefer to use a simpler representation that represents the state less ambiguously. I will prepare a PR.