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

That was more-or-less my first reaction, however there are problems with
just using generate. If the foundary provides you an incomplete set of
models it is difficult to add in your own special case models since you
have to rewrite the generate code (may be impossible if it's delivered
pre-compiled or encrypted from the foundary). Also, if there are bugs in
the generate you could easily get the wrong models without knowing. With
overloading all the models are guaranteed to be considered and it is
easy to add some more of your own if you need to.

Kev.

Steven Sharp wrote:

>>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 14:07:37 2004