Re: Paramset Proposal

Geoffrey.Coram wrote:

>Kevin Cameron wrote:
>
>
>>That would be the wrong way round (IMO) since that puts the potentially best match last.
>>
>>
>
>It's last within the file, but at least the simulator doesn't have to go read in lots of other files that might have been specified as alternate libraries. (In your way of doing things, the order doesn't matter, since the simulator has to check everything anyway, so why would you want the best match first?)
>
>
Ordering the list differently doesn't guarantee that the search will be
faster or slower, since it also depends on the dataset. If there is no
match you search the entire set regardless of the algorithm.

>>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'm citing a case where the selection CANNOT be done except by
>first-match (or flipping a coin). It shouldn't be the simulator's job to check for errors in the library of paramsets -- checking for each instance it looks up, for each circuit, for each simulation.
>
>If the cases were overlapping (not just abutting), you say you'd want at least a warning, but the overlap might actually be a floating-point roundoff problem; I've seen model cards with something like lmin = 0.35u + dl_stat (where dl_stat is chosen appropriate to the fast/slow/nom corner). So, now you have to introduce rules that say, well, OK, they can overlap, but not more than a tolerance ...It quickly gets out of hand.
>
>
I would consider those bad by construction: if one piece of software (or
a single user) is creating the paramsets it should be able to put the
same number in both places and there is no reason they should round
differently, and we have syntax for inclusive and non-inclusive ranges.

>>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.
>>
>>
>
>The detail_level parameter is a paramset-parameter, so the
>information is not in the module. You can then use defparam to set the detail_level for particular instances.
>
>
The SV folks are trying to depracate defparam, so I'd avoid suggesting that.

The procedural approach would be able to compare paramset-parameters.

>>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".
>>
>>
>
>Source order as part of the algorithm is unavoidable, as I proved in my example with bins.
>
>-Geoffrey
>
>
I see no reason why it is unavoidable. No high level language I know of
uses source order in that manner.

If you show me some math proving you can get the best n-dimensional
match with a 1-d first match search maybe I'll change my mind :-)

Kev.

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