The $paramod name mangling is not invertible (the \ character, which
separates the module name from the parameters, is valid in the module
name itself), which does not stop people from trying to invert it.
This commit makes it easy to invert the name mangling by storing
the original name explicitly, and fixes the firrtl backend to use
the newly introduced attribute.
This adds the new rewrite rule. But it's still missing a check that makes
sure the new rewrite rule is actually a valid substitute in the always
block being processed. Therefore the new rewrite rule is just disabled
for now.
Signed-off-by: Claire Wolf <claire@symbioticeda.com>
Before this commit, enum values were serialized as attributes of form
\enum_<width>_<value>
where <value> was a decimal signed integer.
This has multiple drawbacks:
* Enums with large values would be hard to process for downstream
tooling that cannot parse arbitrary precision decimals. (In fact
Yosys also did not correctly process enums with large values,
and would overflow `int`.)
* Enum value attributes were not confined to their own namespace,
making it harder for downstream tooling to enumerate all such
attributes, as opposed to looking up any specific value.
* Enum values could not include x or z, which are explicitly
permitted in the SystemVerilog standard.
After this commit, enum values are serialized as attributes of form
\enum_value_<value>
where <value> is a bit sequence of the appropriate width.
(parameters in systemverilog packages can't actually be overridden, so
allowing parameters in addition to localparams doesn't actually add any
new functionality, but it's useful to be able to use the parameter
keyword also)
- information also useful for strongly-typed enums (not implemented)
- resolves enum values in ilang part of #1594
- still need to output enums to VCD (or better yet FST) files
Before this commit, every initial assignment to a memory generated
two wires and four assigns in a process. For unknown reasons (I did
not investigate), large amounts of assigns cause quadratic slowdown
later in the AST frontend, in processAst/removeSignalFromCaseTree.
As a consequence, common and reasonable Verilog code, such as:
reg [`WIDTH:0] mem [0:`DEPTH];
integer i; initial for (i = 0; i <= `DEPTH; i++) mem[i] = 0;
took extremely long time to be processed; around 80 s for a 8-wide,
8192-deep memory.
After this commit, initial assignments where address and/or data are
constant (after `generate`) do not incur the cost of intermediate
wires; expressions like `mem[i+1]=i^(i<<1)` are considered constant.
This results in speedups of orders of magnitude for common memory
sizes; it now takes merely 0.4 s to process a 8-wide, 8192-deep
memory, and only 5.8 s to process a 8-wide, 131072-deep one.
As a bonus, this change also results in nontrivial speedups later
in the synthesis pipeline, since pass sequencing issues meant that
all of these intermediate wires were subject to transformations such
as width reduction, even though they existed solely to be constant
folded away in `memory_collect`.