Re: Paramset Proposal

Geoffrey.Coram wrote:

>Kevin -
>I don't understand what you mean by "appears to match": either
>an instance fits the paramset constraints (matches) or it doesn't.
>
>
OK, it matches. It just might be sub-optimal.

>I believe it is sufficient to specify that the "search algorithm"
>is first-match. Then the person writing the paramset files knows
>to put the "quickest" (least detail) paramsets first and the
>others later.
>
>
That would be the wrong way round (IMO) since that puts the potentially
best match last.

>I still maintain that it's impossible to write a complete search
>algorithm that will automatically pick a model in every case,
>without resorting to a first-match to resolve some ambiguity.
>
A purely procedural approach would be capable of doing that.

Note: I think you can add procedural selection on top of whatever other
search algorithm
you want - it's not exclusive. Users could add procedural paramset
selection on top of vendor
supplied model lists.

>In a typical spice netlist, you'll have "bins" for the mos
>devices, and an instance that falls right on the boundary
>could be simulated with either:
> m1 d g s b nmos l=1u w=1u
> .model nmos.1 level=49 lmin=0.18u lmax=1u ...
> .model nmos.2 level=49 lmin=1u lmax=2u ...
>
>Which one is "right"? Either one should be acceptable to
>the user (and if the binning has been done right, he'll get
>the same answer). You don't want to abort the simulation and
>tell the user that he has to be more specific. You can't say
>that the model cards have to be converted to paramsets with
> parameter real l = 1.0 from [lmin:lmax);
>because then an instance with l=the largest lmax would not
>get matched to a model; similarly for lmin if the range
>were (lmin:lmax].
>
Your citing a case were the choice is probably immaterial, however, if
there was
a mistake in the model paramset definition (i.e. incorrectly overlapping
cases) I
would like to get a warning (at least). I prefer it to be defined as an
error in the LRM
and allow vendors to provide overrides.

>I think the burden should be on the paramset/library writer
>to provide a method to match instances to specific paramsets
>when the user needs to specify. One could use a parameter
>like "detail_level": if each paramset has detail_level set
>to a different value as default, and only the default value
>is legal
> parameter integer detail_level = 1 from [1:1];
>then the user can leave it blank when the first-match is
>good enough, or specify the detail_level to ensure a
>specific match...
>
I would prefer to leave that information out of the module and put it in
the paramset
itself - e.g. add a parameter to the set indicating its detail level
and switch on it
procedurally.

> I don't believe we need to define a
>search in the LRM.
>
>-Geoffrey
>
I think this needs to be defined a lot better than it is currently, and
source order as
part of the algorithm is a complete "no-no".

Kev.

>Kevin Cameron wrote:
>
>
>>What you're proposing is that even if I specify all the possible
>>paramsets
>>they won't necessarily be considered since as soon as one is found that
>>appears to match the simulator is going to give up looking.
>>
>>At a minimum I think you need to specify a search algorithm that is
>>going
>>to start with paramsets that have the most matching localparams and
>>works
>>down, and if there is ambiguity the user should be able to provide rules
>>for disambiguating: it should not depend on source order.
>>
>>Kev.
>>
>>

-- 
Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862