[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