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

> Grouping defparams into a separate file is one of the abuses that came 
> into
> existence with defparams.
>
> In my discussions with Shalom, about the only reasonable use for the
> deprecated defparam is to change parameters hierarchically-down from the
> current module without the need to pass the parameter through multiple
> levels, which is what I currently advocate.
>
> A future extension to SystemVerilog might permit downward hierarchical
> named parameter passing, of the form:
>
> alu #(.u1.SIZE=8) alu1 (.*);
>
> Where u1 is an instance instantiated inside of the alu1 instance of 
> the alu
> module, and SIZE is a parameter inside of the u1-instantiated module.
>

The claim in 26.2 that defparams don't provide functionality beyond that
of instance overrides is inaccurate. Using instance overrides

- One cannot override parameters in a subscope of the instantiated module.
- One cannot override parameters of a top level module.

There is a typo in the suggested extension above: should use parenthesis
instead of '=' in the override, so would read alu #(.u1.SIZE(8)) alu1...
The abovementioned scheme could be extended to address parameters
in subscopes. In the example below, the override could be foo 
#(.fun.p(5)) f();
But it is unclear how top level module parameters could be overriden.

To illustrate the subscope issue condider the following example

module top;
   foo f();
   defparam f.fun.p = 5;
endmodule // top

module foo;
   function fun;
      input in;
      parameter p = 3;
      $display("In fun, p = ", p);
   endfunction // fun
   integer      i;
   initial i = fun(1'b0);
endmodule // foo

This will print

fun has p =           5

    _Matute