Fix illegal signal names generated from real literals #757
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For signals without source names, BSC constructs a name based on the assigned expression. If the expression contains a number, that number appears in the name. BSC filters out a few characters, such as decimal points (
.
) but was not eliminating negative signs (-
) which can show up if aReal
literal is small enough that E notation with a negative exponent is used. In that case, BSC was generating a signal name with a negative sign in it, which is not legal for names in Verilog or Bluesim. In the Verilog backend, such names are probably inlined anyway, but I ran into a situation ($display
of aReal
value) where the signal survived in Bluesim and caused a C++ compilation failure.Filtering out the decimal point causes a real number to look like a large integer, which was confusing when I saw such signal names. So instead of fixing this bug by adding
-
to the list of characters to be removed, I changed BSC so that it replaced decimal points byd
and negative signs byneg
, so that the value in the name is not misinterpreted.