Re: [sv-ec] Quick poll for AMS extension to overload modules

>As Shalom notes, the paramsets proposal
>http://www.eda.org/verilog-ams/htmlpages/public-docs/paramsets-v4.pdf
>discusses many features.

OK, I have read most of this now. I skipped the more SPICE-oriented
portions, as they are outside my area of expertise. My comments are
based on an understanding of digital Verilog, and may not be fully
applicable to issues that come up in the analog area.

>As Steven noted, you can instantiate different modules
>(eg, one of the M1 instantiations could be bsim4 instead).
>
>However, each of the instantiation lines needs to have the
>O(100) parameters specified, which looks pretty ugly.

Note that the paramsets have to specify the parameter values
also. They have to be specified somewhere. I don't really
see much difference between instantiating a paramset (which
has a default set of parameter values defined in it and a
lower-level module to instantiate) and instantiating a wrapper
module that has that set of parameters defined in it with those
same default values, and then instantiates a lower-level module
with those parameters.

It is a little inconvenient syntactically to have to pass those
parameters from the wrapper module down into the lower-level
module. My first response to that was the same as Shalom: extend
the SystemVerilog .* port connections to allow .* parameter
overrides also. That would allow the wrapper module to pass all
its like-named parameters down to the lower-level module, without
having to do so explicitly. The .* port connections take care of
connecting the wrapper ports to the lower-level module ports.

Yes, this adds an extra level of hierarchy for the wrapper module.
I just don't see that as a severe enough problem to warrant a completely
new construct.

> All
>of the nmos models have to be specified in this master
>module: all the bins, fast/slow/nominal corners, pre- and
>post-layout models, etc. Typically, corner models are
>grouped together: fast nmos with fast pmos, slow nmos with
>slow pmos.

They can be grouped together physically within the generate.
They can be separated into different files by use of `include.
They can be separated more thoroughly by having multiple levels
of wrapper module (e.g. a conditional-generate selects an nmos
wrapper or a pmos wrapper module, and that module selects a
fast or slow wrapper module). This does have the disadvantage
of adding additional levels of hierarchy.

Also, a lot of these things are not sounding like they are
selected individually by the parameters for different instances.
If they are being selected on a whole-design or region of a
design basis, then Verilog configurations can be used to select
different module bindings.

> It's an extra hurdle for the foundry
>characterization group to change the way they think.

It seems to me that this is just part of making the transition
to Verilog-AMS. It isn't going to be exactly like what they are
used to, and there will be some learning required.

Steven Sharp
sharp@cadence.com
Received on Wed Jun 23 13:34:21 2004