Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

parameter array of strings causes an syntax error #101

Open
fpgauserdude opened this issue Sep 6, 2024 · 4 comments
Open

parameter array of strings causes an syntax error #101

fpgauserdude opened this issue Sep 6, 2024 · 4 comments

Comments

@fpgauserdude
Copy link

localparam string TESTED_VERSIONS[] =
   {
     "2023.1",
     "2023.2"
    };

$ svinst test.sv
files:
parse failed: "test.sv"
test.sv:72:42
|
72 | localparam string TESTED_VERSIONS[] =
| ^

The syntax is maybe a little weird, but perfectly legal. This code compiles on a commercial tool.

@dalance
Copy link
Owner

dalance commented Sep 13, 2024

According to Formal syntax of LRM, localparam can take unpacked_dimension only, so [] can't be used.

local_parameter_declaration ::= localparam data_type_or_implicit list_of_param_assignments
list_of_param_assignments ::= param_assignment { , param_assignment }
param_assignment ::= parameter_identifier { unpacked_dimension } [ = constant_param_expression ]
unpacked_dimension ::= [ constant_range ] | [ constant_expression ]

@fpgauserdude
Copy link
Author

I changed the code to the following

localparam string TESTED_VERSIONS[2] =
   {
     "2023.1",
     "2023.2"
    };

And the parse does work.

But the only way I discovered this problem was by using sv-parse. Every other SystemVerilog tool that I am aware:.

Vivado, Questa, Quartus, even Verible (another FOSS tool) parse this code just fine.

@dalance
Copy link
Owner

dalance commented Sep 13, 2024

For example, Synopsys Formality outputs syntax error to this code.
A purpose of sv-parser is detecting such corner cases (almost all tools work fine, but some tools don't) by implementing as Formal syntax is.

@fpgauserdude
Copy link
Author

I can appreciate the value of finding code that is not strictly compliant with the LRM. Sometimes I think that HDL tool vendors do not do the developer community any favors by allowing code that is non-compliant.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants