Description
I have Verilog that I want to be common & the same for simulation and synthesis, but there's an incompatibility when Yosys gets to this #DELAY in procedural continuous assignment.
assign #(DELAY_RISE, DELAY_FALL) Y = computed;
Actual behavior:
ERROR: syntax error, unexpected ','
Expected behavior:
I guess Yosys is supposed to throw away the DELAY specification (it's not for synthesis). It accepts a single DELAY value no problem. Can we enhance it to accept a pair or a triplet; that is, with commas as below in A.2.2.3?
Incidentally Yosys also accepts:
assign #(DELAY_RISE : DELAY_RISE : DELAY_FALL) Y = computed;
...this is min-typical-max form, which is different and isn't for my use case.
Workaround:
I've not had a need to use `ifdef SYNTHESIS so far. But without fixing this front-end parsing, I might have to use it.
Background:
I looked in the LRM. (Yes, I must be enthused about this.) Some technical definitions:
delay3 ::= (From Annex A - A.2.2.3)
# delay_value | # ( delay_value [ , delay_value [ , delay_value ] ] )
delay2 ::=
# delay_value | # ( delay_value [ , delay_value ] )
delay_value ::=
unsigned_number
| parameter_identifier
| specparam_identifier
| mintypmax_expression
mintypmax_expression ::=
expression
| expression : expression : expression
Also we can see the reason for existing constraint in a front-end parser file:
non_opt_delay:
'#' TOK_ID { delete $2; } |
'#' TOK_CONSTVAL { delete $2; } |
'#' TOK_REALVAL { delete $2; } |
'#' '(' expr ')' { delete $3; } |
'#' '(' expr ':' expr ':' expr ')' { delete $3; delete $5; delete $7; };
There's no good reason for rejecting the delay2 or delay3 format, is there?
If you're good with it, do you want me to do the PR? Thanks