Closed YikeZhou closed 4 months ago
Thanks for filing this! I would guess that string variables are not synthesizable because they have dynamic width. Can you share more context on your use case? If this were a localparam, this could work, but sv2v doesn't yet support string methods like getc
.
Hi, thank you for taking the time to review this.
Can you share more context on your use case?
You see, a month ago, I compared sv2v and Synlig using various SystemVerilog examples. I encountered a few snippets that resulted in Verilog code being rejected by other tools such as Verilator. I must apologize if I've flooded the bug tracker with corner-case issues since I didn't come up with any related use cases.
I would guess that string variables are not synthesizable because they have dynamic width.
As far as I know, using "string" as constant numbers is quite uncommon in actual Verilog code. However, I did refer to IEEE Standard for Verilog Register Transfer Level Synthesis and noticed that "string" is included in the syntax summary annex. This synthesis standard itself does not provide a specific explanation or definition for "string". Section 5.2.3 of IEEE Standard for Verilog Hardware Description Language (1364-2005) does provide a definition. The problem is that I'm not sure it should or should not be conformed in synthesis.
Although IEEE 1364.1-2002 states that strings are synthesizable, I think IEEE 1364-2005 Section 3.6.1 makes it clear that these are not dynamic strings:
String variables are variables of
reg
type (see 4.2) with width equal to the number of characters in the string multiplied by 8.For example:
To store the 12-character string "Hello world!" requires a
reg
8 * 12, or 96 bits wide.reg [8*12:1] stringvar; initial begin stringvar = "Hello world!"; end
What do you think?
I'm closing this as I don't believe this construct is synthesizable in general. Please feel free to reopen and correct my understanding!
A problem similar to #224.
Input:
Output:
And some Verilog tools do not support
string a
.