RE: [sv-bc] Defparam on member of parameter struct

>The line between "possible deprecation" and "actual deprecation" is
>opinionated. The 1364-2005 LRM "actually" deprecated the ACC/TF PLI
>routines. That means someone could build a simulator and claim to be
>Verilog compliant without implementing the ACC/TF routines. In reality,
>that's not going to happen for awhile. 
>
>If I knew that the 1364 was going to actually deprecate the ACC/TF
>routines, I would pushed harder to the actually deprecate defparam.

It doesn't matter whether these things were "possibly deprecated" or
"actually deprecated", because "deprecated" does NOT mean "removed".  It
just means "discouraged" or "not recommended".  "Actually deprecated" can
mean "possibly removed in the future", but that is as close as it gets.

So defparam is still part of the SystemVerilog language.  Its interactions
with other SystemVerilog features still need to be well-defined.  However,
I think there is consensus that we won't be making extensions to defparam
for new language features.

The original question was whether a defparam can be applied to a member
of a struct.  I don't believe that this is legal by the existing LRM.
And with the deprecation of defparams, it is unlikely that there will
be any extension to make it legal.

Even without the deprecation of defparams, there would be issues with
this.  There is no precedent for being able to override a subpart of a
parameter (e.g. a bit select or part select), with either defparam or
instantiation.  There would be problems with this.  An override of a
parameter without a type will not only override the value, but also the
type of the parameter.  If you don't override the entire parameter at
once, then the meaning of this can become unclear.  While it is possible
to add restrictions to deal with this, it adds unnecessary complexity.

Steven Sharp
sharp@cadence.com