Re: Quick poll for AMS extension to overload modules

Since the original question was whether or not paramsets were the best
way to do module overloading, here is an alternative method using
macromodule syntax.

The [macro]module syntax is extended to include inheriting the interface
(ports & parameters) of another module or primitive, the head of the
declaration:

    module_keyword [ lifetime ] module_identifier [ parameter_port_list
    ] list_of_ports ;

Becomes:

    module_keyword [ lifetime ] module_identifier [[const] interface
    parent_mod] [ parameter_port_list ] list_of_ports ;

    parent_mod ::= module_identifier | udp_identifier | primitve identifier

For example:

          macromodule n_spice interface nmos; // base n_spice on digital
primitive
            parameter real l,w; // add length,width
          endmodule
          macromodule my_n_tran interface n_spice; // inherit l/w from
n_spice
            parameter my_parm1; // add some more parameters
          endmodule

Which means that the macromodule my_n_tran has the same ports and
parameters as nmos but has the extra parameters l,w and my_parm1. That
makes it easier for tools to recognize that a user defined component
is a variation of a primitive for automated rule-checking or symbol
location etc. Extra ports can be added so that it is possible to do
something like adding a substrate contact for a transistor model, or an
extra control line for a sequential block (e.g. a reset):

          macromodule nmos_sub interface nmos (inout sub); // inherit
from digital primitive and add a substrate port
            ntran_sub #(.*) (.*); // instantiate 4-port device
         endmodule

- I added ".*" for connecting parameters as well as signals (Verilog-A
BSIM models can have hundreds of parameters).

For binning (the main aim of paramsets) I would use the same localparam
syntax, so the following example overloads binned_bsim6 using the
generic bsim6 model interface:

    macromodule binned_bsim6 const interface bsim6;
        localparam real l from [0.0,1.0e-6); // use this model for
gate length < 1u
        bsim6_short #(.*) (.*); // short gate model
    endmodule

    macromodule binned_bsim6 const interface bsim6;
        localparam real l from [1.0e-6,inf); // use this model for gate
length >= 1u
        bsim6_long #(.*) (.*); // long gate model
    endmodule

The use of const implies that the user cannot override any parameter
but l for these macromodules to be instantiated (all other parameters
are inherited).

Otherwise the [macro]module behaves the same as a regular module so you
can instantiate extra components add monitoring processes or whatever
you like.

The reason for proposal above is that it provides the functionality
that the paramsets proposal does but reuses an existing construct (so
fewer new keywords), and adds some extra functionality for design rule
checking etc.. Also if you want to inherit more than the ports and
parameters (at some future time) you can add "extends" or ":" as an
alternative to "interface" in the sysntax and do module inheritance much
the same way as class inheritance (e.g. overriding task and function
definitions).

Comments?

Kev.
Received on Mon Jun 21 10:50:45 2004