RE: [ng-spice-devel] An Historical note on spice netlist format


To "'ng-spice-devel@ieee.ing.uniroma1.it'" <ng-spice-devel@ieee.ing.uniroma1.it>
From "Gillespie, Alan" <Alan.Gillespie@analog.com>
Date Wed, 7 Feb 2001 15:24:55 -0000
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
Reply-To ng-spice-devel@ieee.ing.uniroma1.it


I agree completely that we should be aiming to replace
the whole syntax with a better one. Eventually. But
designing a complete new syntax is non-trivial, if
we're to get it right.

I think Al's looking for a simple extension that get's
us over the immediate problem (not enough letters left
for new devices), and doesn't involve a completely
new (incompatible) parser.

On the other hand, it would be neater if the "fix"
we do now didn't look out of place in the "final"
syntax. So if we could decide on a device line
format that we can keep in the eventual new syntax,
then it would make everybody's life easier.

Paolo's format of -

resistance <node1> <node 2> model=<modelname> param=value ....;

is not dissimilar to Al's original proposition -

.resistor R12 (1 2) 10k

Paolo, did you intend the "resistance" to be the name of the
device, or did you mean it to be the type, with another field
possibly between "resistance" and <node1> to be the name ?

Actually, looking back at Al's original stuff, I don't think
he's got an example of a device with both a device type and
a model name on the line. I assume, Al, that you were intending
the model name to be in the usual position, i.e. between the
node list and the parameter list.

In Al's example above, the "10k" as assumed, by virtue of its
position on the line to be the value parameter for the device.
Spice, at the moment, has a set number of "position implied"
parameters for each device, and then optional parameters
which must be set with "param=value" pairs. This mix is
defined on a per-device basis, and is a nightmare when it
comes to making a general purpose parser which would work
for all devices.

For generality, I think it's best at this stage to say that
all parameters should be set by "param=value", even the
parameters that are currently implied, e.g. resistor value,
bipolar area, etc.

Paolo has got even the model name as a "param=value" pair.
Apart from laziness, (i.e. not wanting to type it all out),
there's no reason not to do this. In fact, it might be more
"future-proof", in the sense that, eventually, we might
want to have models and "submodels", i.e. a model which
defines most of the parameters of a device, and a submodel
which varies just a few parameters. If that was the case,
it would be inconsistant to have a "position-implied"
model parameter, and the submodel somewhere in the parameter
list.

Also, if we choose the format where the device type is
the specified at the start of the line, then the model
name does not need to be so readily accessible in order
to determine the device type.

So the most general device line might be -

devicetype name nodelist paramlist

where paramlist is a list of "param=value" pairs,
and the nodelist can be either just a straight list
of nodes, or a () or comma delimited list. For the
old (i.e. current) format, this line would be preceded
by a . (or a \ :-)

Note that the most general format would have the nodelist
in the form of a list of "terminal@node" pairs. This would
remove the "position-implied" nature of the nodelist.

So the trade off, as usual, comes down to netlist size
versus generality. Do we want the devicetype and model=
strings to have to be in every device line, and the node-
list to be in "terminal@node" pairs, when the model name
could be in a fixed position after the "position-implied"
nodelist, and the devicetype could be defined by the model.

Actually, I could see a reason for having a model type
whose number of terminals is not fixed. Sometimes we merge
bipolar devices together, so you could have a device which
has a single collector, a couple of bases, and multiple
emitters in each base region. There's no fundamental
reason why a single model couldn't automatically scale
itself for all these possibilities, and in fact there are
good reasons why these kinds of devices should be modelled
as a single unit. To handle this, you'd need the
"terminal@node" pairs, 'cos you couldn't actually guess
anything from the position of the node in a list.

I'm not suggesting that we should consider handling these
possibilities now, just that we should bear them in mind.
For instance, one idea I mentioned earlier was a node list
which was a comma delimited list of nodes. This allowed
"defaulting" of arbitrary terminals, but it doesn't allow
variable numbers of terminals. So there's no point in going
for an "extension" that we can already see has some
limitations.

We could, in the mean time, go for a bracketed "position-
implied" nodelist, to allow simple defaulting (of a substrate
node, for example), on the understanding that this could
be fully defined as a bracketed list of "terminal@node"
pairs in the eventual new syntax.

Och, enough havering !!! What about -

[\]nametag ( nodelist ) devicetype paramlist

Where -

nametag is just a name to use when asking for data
to do with this device;

nodelist is initially a "position-implied" node list,
but eventually may also be a "terminal@node" list;

devicetype is a name specifying a particular device
type, although in many ways this is just a documentation
string, because the exact device type may also be implied
by the model (e.g. model level, lateral/vertical bipolar).
There may be some relationship between the devicetype and
the number of nodes expected, but not necessarily;

paramlist is a "parameter=value" list which may include
a "model=modelname", but it doesn't have to (to take the
default model, like resistors and caps, for instance).

The [\] at the start means that to insert this in an old
netlist, you start it with \, but when used in a brand
new source file, you don't need to.

Partial thread listing: