RE: [sv-bc] Type comparisons in non-constant contexts (BNF)

I did not comment when the Mantis was filed because I wanted to think
about it more, which I still have not really done.

 

Genvars appear in constant_primary but not in primary, because they
really are special, and exist only at elaboration time, as the LRM
explains. References to genvars in non-constant expressions are really
references to the localparam with the same name.

 

I agree that ordinarily constant_primary should be a proper subset of
primary, with the except of genvars. The reason I did not write this
before is that I wanted to think about whether there are other special
cases.

 

Shalom

 

________________________________

From: owner-sv-bc@server.eda-stds.org
[mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Brad Pierce
Sent: Friday, July 14, 2006 10:10 AM
To: sv-bc@server.eda-stds.org
Subject: [sv-bc] Type comparisons in non-constant contexts (BNF) 

 

As reported in
http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0001521 --

 

According to the BNF of A.8.3 and A.8.4, it's not possible to ask
whether (type(expr1) == type(expr2)) anywhere except where a
constant_expression is required. But the result of this comparison can
be determined at elaboration time regardless of the context. And there's
usually a clumsy workaround, namely, declaring a local parameter in the
current block and assigning it the result of the comparison.

I think that a type_reference, unlike a genvar_identifier, should not
just be a constant_primary, but also be a primary.  It would still be
subject to the restrictions of footnote A.10.29.

 

And it's not clear at all in the BNF anyway that a genvar_identifier
cannot be a primary, because syntactically it could sneak through as a
hierarchical_identifier, which is how enums and parameters become
primaries even though they, like genvars, are listed under
constant_primary.

 

The cleanest fix would be to remove constant_primary and replace
constant_expression with

 

          constant_expression ::= expression

 

plus a footnote pointing to the relevant text section.  For example, why
couldn't an inside_expression like (P inside {0,2,4,6}) be a
constant_expression if P were a parameter?  Yet, according to the BNF,
it can't.  And for that matter, why couldn't the new case-inside
construct be used with generate?  Yet, according to A.4.2, it can't.

 

Constantness is a semantic issue, not a syntactic one.

 

-- Brad