Pursuing the creation of some analog primitive symbols
(specifically, 4-terminal MOS) with the eventual goal of
a simple, standard analog SPICE library.
I made a symbol (icon) by drawing a schematic, putting ports
on it and letting Electric make the icon facet. That worked,
in that I got a facet w/ pins & a texted box.
When I tried to edit, I had a lot of difficulty in grabbing
the right objects (pins, texts, arcs all over each other,
no obvious way to do selection filtering). Also, creating
the first arc is tricky; it wants a starting vertex, and
if you want to create a line from nothing, you may have to
first place a dummy "pin" and then delete if it doesn't self-
delete. The arcs also want to snap onto anything close, so
in drawing a fine-pitched "pretty" symbol, I had to draw the
lines well apart and then drag them, or they kept on auto-
connecting.
So, anyway, after about an hour of screwing around I had an
artistically nice symbol with four ports on it. I tried
messing with the icon Information to make netlisting use
a model file. The closest I could get was a subcircuit,
using an "expand" source. I did not see any means of
making the device link to an arbitrary name, arbitrary
node sequence, arbitrary argument (ideally, passed-through
icon properties) external model. This is really what I'm
after, is being able to place my own NMOS4_test icon,
somehow tell it that it has W=100, L=0.8, STRIPES=10
and have it pass D, G, S, B port connectivity (in order - the
subcircuit generated with the nodes' order rearranged, no
apparent means of specifying netlisted port order) and N
icon "properties" in a SPICE deck line.
I'm hoping Steve can expand upon the icon-netlist interface,
how one might :
(1) attach properties to an individual instance of an icon
(2) make an icon master "want" specific properties, i.e.
ask for them & default them
(3) pass these properties in the netlist line
(4) cause specific port order in the netlist line
(5) force specific/arbitrary netlist line syntax
e.g.:
netlistFormat='include NMOS4_test.spi i$[instanceName] n$[D] n$[G]
n$[S] n$[B] prop$[W] prop$[L] prop$[STRIPES]'
It may be that this mostly involves the simulation interface tool,
perhaps getting it to look at a side file for netlisting cues
or at the icon for additional properties?
For example, in older versions of our Cadence tools, each symbol
(or cdsSpice) rep had a property called palNetlistProcedure
which indirected the netlisting, referencing startup-loaded
IL functions (as many as you wanted to borrow or write) and
dictating the format and argumenting of the netlist line(s).
Each library had its own cdsSpice.il file pulled up through
the autoload chain of events. Electric seems to have a much
more spare library structure, but maybe it's a lack of
.cadrc elaborateness? Maybe this is something that a TCL
SPICE netlister should be developed for, to layer on some
abstraction?