Should hierarchical names be allowed in value parameter definitions, and more generally, in constant expressions?

[martinwhitaker]

IEEE 1800-2017 section 6.20.2 states

A value parameter (parameter, localparam, or specparam) can only be set to an expression of literals, value parameters or local parameters, genvars, enumerated names, or a constant function of these. Package references are allowed. Hierarchical names are not allowed.

so that is a definite no. For constant expressions in general, the syntax in appendix A also appears to exclude it.

Currently Icarus Verilog will reject the direct use of a hierarchical name in a constant expression, but will accept it as the operand of the $bits function in a constant expression. Other simulators I have tried vary - some allow both, some allow neither.

This is relevant to issue #483 and issue #575. I have a fix for the underlying bug, but need to decide what are valid regression tests.

[caryr]

I would expect if it is not allowed in one context then it should not be allowed in another though $bits() is somewhat special since it is really focusing on the type and not the actual value so I understand why we would think it should work differently. Does the standard talk about type parameters having different rules? If so I would argue $bits() should also behave differently.

[martinwhitaker]

I've just checked, and hierarchical names are also forbidden in type parameter declarations. They are also specifically excluded when the $typename system function is used as an elaboration time constant, but not mentioned in the description of $bits. There is https://accellera.mantishub.io/view.php?id=2856 which says that's an omission in the standard