Re: Paramset Proposal

Kevin -
I don't understand what you mean by "appears to match": either
an instance fits the paramset constraints (matches) or it doesn't.

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.

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.
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].

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 don't believe we need to define a
search in the LRM.

-Geoffrey

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.
Received on Mon May 17 06:52:37 2004