gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] "binning" of models


From: mcmahill
Subject: Re: [Gnucap-devel] "binning" of models
Date: Wed, 16 Jan 2002 08:53:49 -0500 (EST)

Cool Al!  This is a big step forwards in terms of being able to use hspice
libraries as supplied by IC foundries.  

I read through the 2 pages of the hspice manual last night that covered
this and it sounds like how you have implemented it is just fine.  

So on a related topic, any chance of the .param and .lib functionality
too?  

Thanks
-Dan

On Tue, 15 Jan 2002, Al Davis wrote:

> The next release really will have binning.  I implemented it 
> yesterday, and it was very easy.  I don't know if it is strictly 
> HSPICE compatible or not, but it is close.  I believe it is a 
> superset.
> 
> Like HSPICE, there is no check for consistency at bin boundaries.
> 
> It can work for all model "levels".  It is not necessary to use the 
> same criteria for all.  By defining it in the base, it does.
> 
> It is legal for different bins to use completely different models.  
> You could use a BSIM3 for one bin and a level 1 for another.
> 
> If binning parameters are specified, but the model is explicitly 
> specified, without binning, a warning is issued when it is outside 
> the legal range.
> 
> If full binning is used (implicit selection of the model) and there 
> is no matching bin, this is an error.  (It throws an exception.)
> 
> Here's a basic outline:
> 
> Binned model names end with dot number, such as "foo.1", "foo.2", 
> "foo.3".
> 
> The numbers must start at 1 and be consecutive, but not necessarily 
> in order in the file.  There is no warning or error if they are not 
> consecutive.
> 
> It is still legal to name a model something like "foo.4" and not use 
> binning.
> 
> To use binning, you specify the name without the number.
> 
> M1 2 3 4 5 foo w=2u L=2u
> 
> First, it will look for a model "foo".  If this is available, it will 
> use it directly, without binning.
> 
> If there is no model "foo", it will look for "foo.1".  If a model 
> "foo.1" is found, it is checked for bin matching.  If it matches, it 
> is accepted, else it continues by looking for "foo.2", and so on.  If 
> the model "foo.1" is not found, the search for a match is terminated, 
> and an error issued (exception thrown).
> 
> So, suppose there exist models "foo.1", "foo.2", and "foo.4".  It 
> will try "foo.1", then "foo.2".  Since there is no "foo.3" it will 
> terminate the search, missing "foo.4".
> 
> You can still specify the specific model directly:
> 
> M1 2 3 4 5 foo.2 w=2u L=2u
> 
> If you do this, it will not do binning.
> 
> Well, you could have "foo.2.1", "foo.2.2", ......
> 
> 
> Models now have a new method "bool is_valid(const COMMON_COMPONENT*)" 
> that checks for a valid bin.  It returns true if it is ok, false if 
> not.  It is a virtual function, so if you don't specify it, it 
> inherits it.  This makes it so all MOS models can use the same check, 
> or it can be overridden.  The base for all (in MODEL_BASE), just 
> returns true, which disables binning for that model.
> 
> Using the model compiler, all you need to do to enable binning is to 
> list the parameters where they are expected, and provide a function 
> to check, under "validate".
> 
> That was easy!
> 
> It looks like the next release will have binning and BJT.
> 
> al.
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]