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

Geoffrey.Coram wrote:

>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.
>
I'd rather extend the [macro]module syntax/semantics to support what you
need than add a whole new construct, e.g. add inheritance to
[macro]modules so that you don't have to redefine stuff:

    module mos (...)
       ...
    endmodule
    macromodule my_mos interface mos; // inherit port and parameters
etc. from mos
       ...
       mos #(...) (.*);
    endmodule

I suggest "interface" rather than "extends" (or ":") since you don't
want to inherit the internal structure and processes (and "interface" is
already a keyword). You could use the same approach when creating
different models too:

     module n_generic (inout source,inout drain,input gate);
        parameter real l,w;
     endmodule

     module n_bsimX interface n_generic;
        ....
     endmodule

This is useful functionality since extensions to n_generic would
automatically apply to n_bsimX, and other derived modules, and you can
easily identify all models of a given class. You could also tie analog
models to digital primitives e.g.:

      module n_generic interface nmos;

That would allow tools to know what to do in a digital-only simulation.

>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).
>
>
I don't have any objection to the stuff you are trying to do, I'd just
rather see it as part of a more general mechanism so that more designers
can use it and benefit.

>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?).
>
>
Stopping the users doing "bad" things is more of a VHDL feature than
Verilog :-)

>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
>
>
Judging by the large amount of code I see around here with defparam in
it, I don't think it will be deprecated anytime soon.

Kev.

>
>
>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 10:22:36 2004