[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Problem with spice model in both ngspice and gnucap



On Thursday 29 May 2008, JERRY DUNMIRE wrote:
> I played with the model a bit to see if I identify the
> problem. I thought that gnucap was accepting POLY(1) and not
> POLY(n), but based on your comments I'll guess that gnucap
> was treating POLY(1) as a  symbolic node. There are also
> TABLE sources in the file and I don't think gnucap likes
> those either.
>
> Interestingly the spice models from Linear Technologies, for
> similar op-amps, seem to work (at least there are no errors
> reported) for gnucap. So maybe I'll select an opamp from
> Linear. The Linear spice models do not seem to use POLY or
> TABLE elements.

Some do.  Some do not.  There is a common subset that all 
simulators support.  If you stick to that it will work 
everywhere.  Very few models stick to that subset, because 
there isn't much in it.

I don't expect to ever see gnucap specific models, or ngspice 
specific models.  I don't want to see them.   I really would 
like to see an end to all those vendor-specific models.  We 
need standards.  That is part of what Verilog-AMS and VHDL-AMS 
are all about.   Even if you only use them as an alternative 
netlist format, at least there is a defined standard.

After putting a lot of effort into trying to both be compatible 
and to provide important new functionality, I realized that 
these concepts are mutually exclusive.  This is one of the 
reasons for the language plugins in gnucap.  Since the language 
is plugable, there can be a plugin for each variant.  Since 
they are not built in, new language compatibility can be added 
later, perhaps by a user, perhaps by hacking an existing 
plugin.

Gnucap does support the equivalent to the "TABLE" element, but 
not in a form compatible with Pspice. It is supposed to be 
compatible with Hspice.  It's called "PWL".

Now that you mention it ..  it is a trivial change to make it 
take "TABLE" too.  It looks like it will increase the code size 
by 6 characters...  The syntax is still not Pspice compatible.

Try:
G324 no1 no2 ni1 ni2 PWL (..........)

The Hspice format:
G321 no1 no2 PWL(1) ni1 ni2 (......)
also works.  Some of the regression tests use that format, but I 
think it is ugly.


Someday, there will be a "Pspice" language plugin.  There are 
plenty of other things on my plate, so you might need to wait a 
while.  Since it is a plugin, anyone can do it.  Or, if you 
send money, that will make it happen faster.

Actually, I do have some funding now, but not enough.....  The 
funders are more interested in Hspice, Verilog, and Spectre 
compatibility, and other things.


Now about that op-amp model .....   Most users really don't need 
all that detail.  Most users are misled by the apparent detail.  
You are probably better off with a simple VCVS model, or maybe 
a two stage model with a "dominant pole" between them.  The 
design of such a model should be covered in an undergrad 
electronics or circuits course, when they start talking about 
non-ideal op-amps.

Those fancy models that you get by downloading or from databases 
are usually overkill.  If you don't understand them, use a 
simpler model.

Teachers that teach you to just use the magic model, without 
understanding it, are doing a lot of harm.


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