Re: [sv-bc] Defparam -- mixed message from IEEE standards

I didn't appreciate defparam's sequential semantics until I asked myself:
How many defparams can affect one parameter instance?
Is there a rule to arbitrate disputes?

> In the case of multiple defparams for a single parameter, the parameter takes the value of the last defparam
> statement encountered in the source text. When defparams are encountered in multiple source files, e.g.,
> found by library searching, the defparam from which the parameter takes its value is undefined.

In the world of Verilog-2005, that definition is satisfactory because
the module instantiations affected by the defparam are unresolved references
which need only cosmetic editing to install the revised parameter value.

But in System Verilog, we've introduced a port coercion that reaches
outward from the module instantiation and affects the type balancing of the
port expressions.  Those types are informed by the parameter values, and
yet a later defparam may modify them.  When, then is it safe to elaborate
the port expressions?  Does this have to wait until the down design needs
to be elaborated?  How does that square with defparam's standing in the normal
sequential flow?

Greg Jaxon