Hello Kevin and Goeffrey,
It looks like this topic has generated a large amount of email
traffic. Can I ask you to do the following favor, please:
1- Put a proposal together that summarize the following:
a- The problem that you are trying (Verilog-AMS) to solve.
b- Desired features that you would like (Verilog-AMS) to see to
address the problem.
b- Add a section on proposed solutions (different ideas that people
so far proposed).
2- Set up a special meeting and discuss this in length and agree as a
committee on the proposal, solutions and agree on an approach.
Make sure that Sri is in agreement prior to publication.
We must operate under the following operating guidelines (as you
have seen from the feedback):
1- The solution must be compatible with IEEE Verilog 2001 standard. We
cannot afford to get broken tools or models. The goal of the current
Verilog-AMS LRM, is to be compatible and not to ask for enhancement.
2- The solution should not conflict with SystemVerilog 3.1A standard.
3- The solution should be easy to mode and use.
Best Regards
Vassilios
-----Original Message-----
From: owner-verilog-ams@eda.org
[mailto:owner-verilog-ams@eda.org] On Behalf Of Kevin Cameron
Sent: Wednesday, June 23, 2004 11:08 PM
To: Steven Sharp
Cc: gjcoram@eda.org; Shalom.Bresticker@freescale.com;
sv-ec@eda.org; verilog-ams@eda.org
Subject: 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 Thu Jun 24 00:10:39 2004
This archive was generated by hypermail 2.1.8 : Thu Jun 24 2004 - 00:10:48 PDT