Closed bpadalino closed 7 months ago
This is fixed in 125d95bc6f but I had to change
subtype PRODS_RANGE is integer range sfixed_high(H(H'low),'*',in_sample.re) downto sfixed_low(H(H'low),'*',in_sample.re) ;
to
subtype PRODS_RANGE is integer range sfixed_high(H(H'low)'high,H(H'low)'low,'*',in_sample.re'high,in_sample.re'low) + 1 downto sfixed_low(H(H'low)'high,H(H'low)'low,'*',in_sample.re'high,in_sample.re'low) ;
Because according to the static elaboration rules in 14.4 a signal's value cannot be read until after the entire design hierarchy is elaborated and we cannot tell at analysis time whether sfixed_high
will actually read the value or not (this check was missing for subtype declaration). The + 1
is required because "*"
returns an extra carry bit.
Slightly confused about the static elaboration rules. Is the issue because H is unconstrained at the entity declaration?
Questa gives me a warning sounding similar:
** Warning: test.vhdl(397): (vcom-1013) Subtype "PRODS_RANGE" depends on value of signal "in_sample".
Is this something that could be turned into a warning with relaxed rules?
Slightly confused about the static elaboration rules. Is the issue because H is unconstrained at the entity declaration?
No, it's because a signal has no value until after the whole design is elaborated and the initial signal values are calculated. The left and right bounds of the subtype range are evaluated when the subtype declaration is elaborated and passing a signal to a function counts as reading it. From section 14.4:
In addition, if a primary in such an expression is a function call, then the value of any object denoted by or appearing as a part of an actual designator in the function call shall be defined at the time the expression is evaluated.
It downgrades to a warning with --relaxed
already as long as the signal's subtype is fully constrained or it has a default value. The way this works is a bit of a hack though and I'd rather get rid of it but I think it was required for UVVM at some point.
Attached is a design I was fiddling with today that tried to make a fully generic complex package and use some of the sfixed types. Questa seems to run and consume the code with no errors, so I figure it isn't terrible.
Unsure if it has something to do with the resolved nature of
sfixed
versus the results of the functions beingUNRESOLVED_sfixed
, but I think Riviera PRO has that issue.