> -----Original Message-----
> From: geoffrey.coram@analog.com [mailto:geoffrey.coram@analog.com]
> Sent: Friday, May 14, 2004 11:23 AM
> To: Kevin Cameron
>
> Kevin -
>
> Spice .model cards are frequently defined within a subckt,
> and the simulator is expected to match instances in the
> subckt with that .model (with essentially no search) --
> not go out to the library file mentioned at top level.
> Your suggestion to do some other sort of search is simply
> not compatible.
That may be true for .model in Spice, but I don't see why Verilog-AMS
should be doing that. The only requirement on Verilog-AMS is that it
supports the functionality in Spice: it doesn't have to do it the same
way. Neither Verilog-AMS nor SytemVerilog have file or library "scope"
in any very meaningful sense.
> Kevin Cameron wrote:
> > > If the corner matches but l&w don't, that's not a match.
> > Yes, but if I have a both set and the paramset only requires
> > one: that will be a match regardless of a potentially better match.
>
> If you have them "set" then you must have specified them as
> instance parameters, and the simulator must find one that
> matches both.
>
> If you specify L and W in a spice netlist, and there's a
> set of model cards in the library, one of which matches L
> (lmin<=L<=lmax) but the foundry forgot to specify wmin,wmax,
> that's an error on the part of the foundry. The simulator
> shouldn't have to go looking for another model card that
> does have wmin,wmax and W is in that range.
>
It don't see any circumstances in which I would prefer the simulator
to take the first matching paramset if there is a better one available.
My general rule is that the simulator should favor accuracy at all
times.
Any decision otherwise should be left to the user.
> > If there are still multiple applicable paramsets the search
mechanism
> > should start with the most restricted and work down, e.g. if there
is
>
> I doubt you can set up a complete set of rules. What if you
> specify 3 things, and the simulator finds it can match 2 of 3
> for three different models (L&W, L&corner, W&corner) -- does it
> now say, gee, the lmin/lmax bounds are tighter, so that's a
> "more restrictive" paramset? You'll get down to something
> where it will essentially be a coin flip.
That's why the proposal is deficient. The rules for resolving
disciplines
are complicated for very similar reasons: it is difficult ahead of time
to
tell which disciplines will be connected, so you can always add more
rules
to cover new cases e.g. if disciplines a and b are connected and you
want
to use b by preference, you just add: connect a,b resolveto b;
Under no circumstances should the simulator be "guessing" intent.
> > NB: Stuff entered through GUIs tends not to have much ordering to
it.
>
> The schematics will be done through GUIs, not the library files.
You have no guarantee that that is true.
The number of parameters and parameter configurations is semi-infinite
I don't think a 1-dimensional first match search is really going to be
adequate, and I suspect it is mathematically impossible to always get
the best paramset even if the users and tools sort the paramset list.
Kev.
>
> -Geoffrey
Received on Fri May 14 14:49:01 2004
This archive was generated by hypermail 2.1.8 : Fri May 14 2004 - 14:49:12 PDT