Shalom -
On Thu, 17 Jun 2004, Shalom Bresticker wrote:
> I found a much more detailed proposal on paramsets on
> http://www.eda.org/verilog-ams/htmlpages/compact.html
>
> This is much more detailed than the information which appears in the AMS
2.2/DraftE.
> If the intention of the DraftE doc is to implement the proposal doc, then
it needs
> much
> more detail. Currently DraftE simply does not implement what the proposal
says.
> I think copy-paste of most of it, with only minimal editing, would
suffice.
If you think that the paramset proposal is fine as is, I'd
be happy to cut&paste. :) I'm still working through it to
clear up ambiguities. I believe DraftE covers through 2.8
of the paramset proposal. The hierarchical references in 2.9
(to statistics.da) need to be introduced with care, since they
reference variables (which aren't set at elaboration time) and
misuse of hierarchical references in an analog block could
result in a module that could not be simulated (would never
converge in the analog solver).
For the record, I'd like to tweak Kevin's description:
> > Kevin Cameron wrote:
> > > What this does is allow different modules to be selected for a given
> > > instance depending on the instance parameters, i.e. the paramset name
is
> > > treated as being like a module name, and there are multiple paramsets
> > > with the same name - one is selected according to the instance
> > > parameters and its associated module wil be instantiated.
The main idea is to replace the Spice .model card (but to do so
in a much more flexible way). Typically, the paramsets will all
refer to the *same* module, but with different parameters assigned.
Eg, all paramsets will refer to BSIM3, but each paramset will be
tuned for devices with a particular range of geometries (Spice
uses LMIN and LMAX, and for an instance with a specified LENGTH,
automatically picks the .model card for which LMIN <= LENGTH <=LMAX.)
Model cards in Spice often have 100 or so parameters specified
(out of several hundred available in BSIM3).
(The paramset proposal does indicate cases in which the paramsets
might refer to different modules, eg one for analog and another
for digital circuitry.)
Back to Kevin's original question: does it make sense to introduce
the paramset mechanism, or should we try harder to fit this into
some extension of the syntax/semantics for (macro)modules?
-Geoffrey
Received on Thu Jun 17 11:59:30 2004
This archive was generated by hypermail 2.1.8 : Thu Jun 17 2004 - 11:59:51 PDT