Re: VAMS-CM: new LRM draft, DAC meeting

Kevin -
One problem with module overloading is that it adds
a level of hierarchy. In particular, if I've defined
output variables for my base module
  (* desc="transconductance"*)
  real gm;
then if I use overloaded macromodules to set the parameter
values and instantiate a single base module, each of my
macromodules needs to re-define the output variables.

For paramsets, we say that the module's output vars are
brought out to the instance automatically, through any
number of intervening paramsets (we also provide a
method to block this, if desired, and to define new
output variables for the paramset).

Bringing output variables from modules out to their
parents would not be the right thing in general; it
might work sometimes if the module only has one element
inside it and the ports all match up (what if you have
a 3-terminal mos module that instantiates a 4-terminal
mos and shorts the body and source: what does "cbs"
mean?).

Another problem is, if defparam is deprecated as SV has
threatened, then trying to set all the parameter values
of the base module on the instance line in the overloaded
module gets really ugly: you have to put on the order of
100 values in the #(.parameter(value)) section of the
instance line.

-Geoffrey

Kevin Cameron wrote:
>
> While I agree the paramset functionality is desirable, I still think it
> would be more useful as an extension of [macro]modules than as a
> seperate syntactic item. Module overloading is useful functionality, and
> I feel you should be able to do it with minor extensions to the existing
> syntax and elaboration semantics. If a later committee decides to do
> module overloading then paramsets (as described) would probably become
> redundant syntactic baggage.
>
> At a minimum it should probably be run by the SV committee to see which
> they would prefer.
>
> Kev.
Received on Thu Jun 17 08:45:07 2004