Re: Paramset Proposal

Geoffrey.Coram wrote:

>Kevin Cameron wrote:
>
>
>>If you are going to accept partial matches - i.e all the localparams in a paramset match the instance but not all parameters of the instance are specified in localparams for the given paramset - then it is possible that more than one paramset is valid. Your method of selecting between valid sets is to just take the first found, which has the only merit that it might be quicker. It leaves the user with a mathematically hard problem of sorting their paramsets so that the right one always gets chosen (if it is actually possible in the general case).
>>
>>Verilog-AMS is a general purpose language so it has to be able to handle things in a general manner - beyond what Spice can do. While your approach may well work for simple binning, the language doesn't restrict the user to that, so it should handle the more complex cases properly.
>>
>>Also, it's an assumption that linear search first-hit is going to be faster. Since the dataset is fixed you would probably index it in such a way that any search is about the same order - which is dependent on the number of variables. Source ordering is actually an extra variable in the search so is likely to make the process slower rather than faster in general.
>>
>>
>>
>
>
>I agree in principle with the argument that V-AMS is more general
>and should be more powerful than Spice. However, I'm concerned that,
>if the paramset proposal is too hard, or too much of a change from
>what's already in Spice simulators, it may not get approved/used/etc.
>
>
The difficulty in getting things approved doesn't correlate much with
complexity - if it did large chunks of SystemVerilog would have been
thrown out :-)

>I guess what I'm missing is a knowledge of how "most" Spice simulators
>read in their library files. Do they, in fact, read all the libraries
>at the start, and allocate memory for every model card in every library,
>and then start matching instances to model cards? Or do they read the
>netlist and then start looking for model cards, reading in one library
>file at a time if there are still unresolved instances?
>
>If the former, then your approach is fine, and first-match won't be
>much faster, if at all. If the second, then it might be a large
>performance difference, in memory and speed, to switch to your
>approach, and vendors might be very reluctant to do it.
>
>
Generally I don't worry about elaboration-time CPU/Memory usage since
that phase is over fairly quickly and the memory can be recycled for
simulation. I prefer to make sure the language constructs support
incremental compile so that re-running elaboration is fast if little has
changed - e.g. if I add a single extra paramset I would prefer not to
have to recompile the entire source for the design.

>>I would like it to be an error if there is ambiguity - i.e. there should not be two equally good matches.
>>
>>>From my perspective the data supplied to the simulator should be consistent and free of ambiguity, and the simulator should complain if it isn't. Otherwise there is significant risk of hard-to-find errors.
>>
>>
>
>
>In principle, again, I agree with you: it might be hard to find the
>error if caused by ambiguity, and so it would be nice if your
>simulator told you about it.
>
>However, practically speaking, I'm not sure how easy it is to verify
>that a set of model cards is not overlapping. For l&w binning, it's
>"just" a matter of checking the four corners of each rectangle. If you
>now add area and perimeter, you might have to compute the intersection
>point of the curves "L*W=Amin" and "L*W=Amax" with the rectangles; you
>at least have to check 2**N points if you have bins in N parameters.
>
>
I wasn't proposing checking them all, just the ones that get used i.e.
you only report an error when the search turns up an ambiguity, the
simulator would not go looking for ambiguities (although it would be
nice if the venors added that feature).

>I can also imagine that some vendors might not be as thorough about
>checking for ambiguity; you'd then have a foundry releasing a
>paramset with ambiguity that ran fine in HSpice but not in Adice,
>but the foundry wouldn't be motivated to change the paramset just
>because of some odd error message from an internal cad tool.
>
>-Geoffrey
>
That's why I'd like an approach where you can add (your own) paramsets
in an ad-hoc fashion: you can add extra paramsets as you need them to
cover new corners or compensate for deficiencies in foundary supplied
data. If the foundary paramsets are supplied in a file you can't edit or
move easily or is compiled in then you would not be able to insert a new
paramset easily if you are dependent on source order.

Kev.

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