Subject: Re: [Fwd: comments on paramsets]
From: Geoffrey.Coram (Geoffrey.Coram@analog.com)
Date: Fri Nov 14 2003 - 10:30:45 PST
Jim -
I'm having trouble understanding your points.
In point 1, the proposal doesn't encode the module name.
We have
paramset n180nm bsim6
as an example for the paramset declaration. The instance
examples are in Verilog netlist syntax, but if your simulator
allowed you to use paramset in a Spice netlist, I'd expect a
syntax like
m1 d g s b n180nm l=0.18u w=1u
which looks exactly like what Spice users are accustomed to:
the paramset name goes in the place of the name of the Spice
.model card.
In this format, the user does not see what underlying module
(bsim6) is being used, but I would say:
a) the user shouldn't have to specify it -- designers now
aren't specifying bsim3 or 4, the foundry uses bsim4 for those
devices in a process that require the advanced features and
bsim3 for those that don't
b) allowing multiple objects to be passed would be a nuisance;
as a user, I don't want to have to put "process=180nm" on every
instance; this should be specified at a higher level
Following this latter point, your point 2 is almost valid;
but we don't need an explicit link to the process paramset
to be instantiated, because we can use OOMRs to get the
values we need.
As to point 3, the binning proposed allows people to easily
convert sets of models cards that use the lmin/lmax type of
binning. Allowing conditionals in a paramset would seem to
obstruct the simulator's ability to build a structure to
hold the model/paramset parameters. Also, conditionals in
the paramset would not give you the ability to switch the
underlying module, as in the MOS0 vs BSIM4 example in the
proposal.
-Geoffrey
> After spending some time reviewing and thinking about the paramset
> proposal I have the following thoughts:
> 1. paramsets should be passed on the instance line and not via some
> encoding of the module name. Remember, this is aimed at spice
> users who have decades of passing .model cards.
> Basically, you want the ability to pass to the module instance one
> or more paramset objects. This is cleaner from the user's view
> point as it is clear what model/module they are using and what set
> of parameters they are passing to that model/module. By allowing
> multiple objects to be passed, you can pass in process paramaters
> via one object and geometry parameters via a second object. In
> fact, parameters could take precedence depending on how they are
> passed. Incidence parameters over ride geometry object parameters
> which over ride process object parameters. Or rather than nailing
> things down, paramset objects could have a level associated with
> them which clearly specifies the precedence of which parameter
> values are used.
> Basically, the paramset would be a structure passed in.
> 2. If passing multiple paramsets via the instance line is a problem to
> you, then paramset objects should be able to contain (instance) other
> paramset. eg the geometry paramset would contain a link to the
> process paramset.
> 3. binning would be better handled with precedence rules or if
> paramsets could contain conditional branching.
> 4. the proposed Monte Carlo approach would be expensive keeping track
> of the associated seed values for each instance of the model. I am
> not sure what the alternative is yet. It will require more
> thought.
-- Geoffrey J. Coram, Ph.D. Senior CAD Engineer Analog Devices, Inc. Geoffrey.Coram@analog.com 804 Woburn St., MS-422, Tel (781) 937-1924 Wilmington, MA 01887 Fax (781) 937-1014
This archive was generated by hypermail 2b28 : Fri Nov 14 2003 - 10:31:17 PST