Menu
▾
▴
#939 Concatenation syntax {{PARAMETER}{expr}} fails to compile
closed-wont-fix
nobody
5
2014-12-30
2013-10-03
No
Summary: The concatenation syntax {{expr1}{expr2}} fails when expr1 has indefinite width
Test Program: (test.v)
module test; wire [16:0] demo_a; wire [16:0] demo_b; wire [16:0] demo_c; assign demo_a = {17{1'b1}}; // Compiles assign demo_b = {(17){1'b1}}; // Compiles assign demo_c = {{5'd17}{1'b1}}; // Compiles assign demo_d = {{17}{1'b1}}; // Fails to compile initial #10 $display("demo_a=17'h%x", demo_a); initial #10 $display("demo_b=17'h%x", demo_b); initial #10 $display("demo_c=17'h%x", demo_c); initial #10 $display("demo_d=17'h%x", demo_d); endmodule
Current results:
$ iverilog test.v && ./a.out test.v:12: error: Concatenation operand "'sd17" has indefinite width. test.v:12: error: Concatenation may not have zero width in this context. test.v:12: error: Concatenation operand "'sd17" has indefinite width. test.v:12: error: Concatenation repeat may not be zero in this context. test.v:12: error: Unable to elaborate r-value: {{'sd17}{1'd1}} 5 error(s) during elaboration.
Expected results:
$ iverilog test.v && ./a.out demo_a=17'h1ffff demo_b=17'h1ffff demo_c=17'h1ffff demo_d=17'h1ffff
Patch (workaround, DOES NOT RESOLVE UNDERLYING ISSUES):
diff --git a/parse.y b/parse.y index edfc53c..3c24e24 100644 --- a/parse.y +++ b/parse.y @@ -1516,6 +1516,16 @@ expr_primary delete $2; $$ = tmp; } + /* jmcmullan - TERRIBLE HACK for {{expr1}{expr2}} + * where expr1 has indef. length + */ + | '{' '{' expression '}' '{' expression_list_proper '}' '}' + { PExpr*rep = $3; + PEConcat*tmp = new PEConcat(*$6, rep); + FILE_NAME(tmp, @1); + delete $6; + $$ = tmp; + } | '{' expression '{' expression_list_proper '}' '}' { PExpr*rep = $2; PEConcat*tmp = new PEConcat(*$4, rep);
This is illegal code according to section 5.1.14 of the 1364-2005 standard and section 11.4.12 of the 1800-2012 standard:
"Unsized constant numbers shall not be allowed in concatenations. This is because the size of each operand in the concatenation is needed to calculate the complete size of the concatenation."
If most other simulators accept this code, we could consider changing the error to a warning.
N.B. Development fixes the spurious error messages, so I just get
% iverilog br939.v
br939.v:10: error: Concatenation operand "'sd17" has indefinite width.
1 error(s) during elaboration.
Are you sure this is valid syntax and that it compiles with other simulators?
demo_a and demo_b look to be perfectly fine replications.
demo_c is odd and Icarus may be doing it incorrectly, though gplcver gives the same result. For example should the demo_c R-value be parsed as a replication with a concatenated count or two concatenations that are concatenated. The associativity of concatenation/replication is not specified so either may be valid. Icarus is currently parsing this as a replication with a concatenated count value.
I believe demo_d is invalid no matter the interpretation/associativity since the first concatenation does not have a defined size and that is invalid per 1800-2012 section 11.4.12:
The fact that the replication value does not need to be sized does not change the requirement that the concatenation arguments must be sized. FYI gplcver does not compile demo_d either.
I agree with your argument - and I have further looked into it.
here is the actual code that I'm having an issue with is:
I oversimplified it in my example:
Could it be that parameters have an implicit width?
I expect the other simulators are using "integer width" for the parameter. Icarus does things a bit different in this regard so this may be a real bug in Icarus. Why is this not written as {BAR{1'b1}}? I'm expecting that should compile and run just fine and avoids the whole ambiguity of correctly interpreting {{}{}}.
Many tools will take ANY operation on unsized numbers to be in
turn sized. I've written a detailed description of why I think
this is a mistake that the other tools make and that Icarus Verilog
tries to correct. The short story, {17} is not valid because 17 is
not sized, and wrapping it in a parameter name does not change that.
In the end, what you are trying to do is {BAR{1'b1}}, right? That
is a pretty different thing from what you have actually written.
On 10/03/2013 12:13 PM, Jason S. McMullan wrote:
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
Related
Bugs:
#939Personally, I would code it as {BAR{1'b0}}.
Unfortunately, it's not my code.
Please close this ticket.
I have long disagreed with Steve on this issue. The standard clearly states that the bit length of an expression consisting of an unsized number is the bit length of an integer (table 5.22 in 1364-2005). It also states
"A parameter with no range specification, with either a signed type specification or no type specification, and for which the final value assigned to it is unsized shall have an implied range with an lsb equal to 0 and an msb equal to an implementation-dependent value of at least 31."
So I don't think there's any doubt that {BAR} should be accepted. If Steve still disagrees, I'll extend the -gstrict-expr-width compiler option to cover this case as well.
I agree with you to a point on this. The to a point part is many simulators just say the size is 32 bits and this can truncate a value if it gets too large. In my opinion this is wrong. I think it should be a minimum of 32 bits, but should use more bits if needed to accurately represent the value. There are other places where the compiler reduces the size of constants and this leads to unexpected output results in the run time and causes subtle differences/problem in the vlog95 code generator output.
Okay, I'm closing this as won't fix. I would suggest you ask the original author to change the Verilog code, because what they wrote is at a minimum confusing.