Re: gEDA-dev: verilog-AMS

[Dan McMahill <dan@xxxxxxxxxxxx>]

John Doty wrote:
> On Apr 11, 2007, at 9:22 PM, Dan McMahill wrote:
>
> > I think I recall someone here asking about jfet models at some point. 
> > If you have a verilog-ams simulator, no problem.  Grab the jfet.va 
> > model that Geoff Coram wrote from the designers guide.  Now your 
> > simulator does jfets.
>
> Suppose I don't want just any old JFET, but a J309? With SPICE I can 
> download somebody's model parameters, but with jfet.va what do I do?

here's where perhaps the misunderstanding lies.

I propose from now on we use "model" to mean "the set of device 
equations, examples are bsim3, and resistor".  "model parameter set" 
will be what you typically get from a foundary which will be something 
like "vt0=<some number> tox=<some number> model=bsim3v3".  Final "custom 
model" would be a hybrid of equations with parameters.  Examples are the 
op-amp macro models some vendors provide.

  jfet.va implements the "standard" (for whatever that means) model 
equations for a jfet.  So what you do is the following:

start with your simulator.  realize that it does not support the same 
jfet "model" call that spectre does but the J309 "model parameter set" 
you have are for the spectre jfet "model".  download jfet.va, and 
presto, you now have support for the spectre jfet "model" in your 
simulator and you can now use foundary "model parameter sets".

Suppose you are using a bipolar process and the foundary supplies 
mextram "model parameter sets"?  Since the mextram "model" is available 
in verilog-a, you grab that and now your simulator can be capable of 
using the foundary supplied "model parameter sets".

What if the foundary supplies PSP "model parameter sets" for the MOSFETS 
instead of bsim3?  ng-spice does not include support for the PSP "model" 
directly.  verilog-a is the way the PSP "model" is distributed by the 
developers of the equations.

In other words, one big use of verilog-a and verilog-ams is as a 
standard way to allow new "models" to be developed in a simulator 
independent way and then easily used by different simulators.

> Suppose I need to model an OP184? Or the MOSFETs a specific VLSI process 
> makes? It's fine that you can have DIY models, but often you don't have 
> the information to create them. Or the time.

I guess I'm not doing a good job of explaining things.  I'm not saying 
you do a DIY model for the FETS in a specific process.  What I am saying 
is that you use the foundary supplied "model parameter sets" and that 
verilog-a and verilog-ams (a superset) provide you with a way of making 
sure your simulator is always supports the required "model".

A different case is that some foundaries directly supply a "custom model 
" for some devices that is written in verilog-a.  This is a case where 
without at least a verilog-a capable simulator, you can't even use the 
foundary supplied "custom model".


But the other huge case I mentioned is in higher level modeling.  You 
worked on a sigma-delta chip right?  You could produce verilog-a "custom 
models" of blocks like your comparator or your amplifier to allow faster 
simulations at a higher level in your design.  You may not have the 
accuracy for a full transistor level sim, but there are times when 
you're more concerned with something that simulates fast and does _not_ 
include a bunch of non-ideal effects.


In the OPA184 case, it becomes a question of what form any vendor 
"custom model" may come in.  Anyone who as tried to use vendor macro 
models of op-amps has probably seen that they are often tied to a 
particular spice implementation (polynomial and other variations of 
controlled sources are a big source of minor incompatibility).  If the 
"custom model" is in verilog-a, and you have a verilog-a simulator, you 
should just be good to go.  If you need to model an op-amp and the 
vendor didn't even provide a model, you can quickly produce a verilog-a 
one.

Here's hoping I managed to clarify what I've been trying to say and not 
further confuse the situation.

-Dan




_______________________________________________
geda-dev mailing list
geda-dev@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev