gEDA-user: Hierarchy vs spice-sdb

[John Doty <jpd@xxxxxxxxxxxxx>]

I've run into a real paradigm clash here (as well as the ragged edge of
the docs).

I've experimented adding "source" attributes to a hierarchical
design. This makes navigation much easier. However, it breaks SPICE
netlisting with spice-sdb.

Apparently, gnetlist runs down the sources and expands them before the
spice-sdb backend has a chance to look at the associated symbols. The
result is chaos, with top level cards inserted into subcircuit definitions
willy-nilly.

I see two different approaches here:

1. gnetlist does the netlist expansion, flattening the hierarchy.

2. gnetlist preserves hierarchy, allowing SPICE to do the expansion (the
spice-sdb approach).

One advantage of having gnetlist do the expansion is that you get nice
netnames like X1/OUT (ngspice isn't so friendly). Also, for board design,
a flat netlist is required (at least by the PCB designer I usually deal
with). The "source" mechanism is also nice, allowing the designer to avoid
the difficulties wired-in pathnames cause.

There are difficulties with the current documentation of this. Apparently,
the source schematic must have external connections identified by
connection to symbols, but the exact requirements are not clear to
me. Stuart's spice-subcircuit-IO-1.sym works (!), but the refdes value
must be Pn (n is pinseq) for spice-sdb, while for hierarchical gnetlisting
it must correspond to a pinlabel value.

How global nets are handled (if at all) in hierarchy doesn't appear to be
documented. I get nets named things like X1/GND. Won't work.

OK, what can I suggest?

Viewlogic had a "level" attribute for symbols. Its value was not numeric,
but an arbitrary name. You could tell the netlister to expand hierarchy
down to a particular named level and stop. So, perhaps gnetlist --level
pcb could expand down to the level of solderable components, while
gnetlist --level spice could expand down to the level of subcircuits in
your SPICE library (you might want *two* level attributes for some
symbols, as a SPICE subcircuit might also represent a solderable
component).

It might be easier on the user to give the backend a hook to set the
level before the gnetlist frontend runs.

It would be nice to have consistent hierarchical pin connection and global
network conventions between the two approaches. There may be things harder
to reconcile, though. For example, the schematic for a SPICE-expanded
subcircuit must contain a subcircuit symbol, but if you're going to expand
it as a "source" with gnetlist it must *not* contain a subcircuit symbol.

I've mentioned documentation. The gEDA docs are actually pretty good
(documentation quality for commercial packages seems to be measured in
kilograms of cellulose rather than information content). Nevertheless,
I've identified a couple of puzzles above.

For now, I guess I'll leave out source attributes. The main casualty is
easy navigation of the hierarchy, but I know I can get netlisting to work
right this way. Right now we have two good mechanisms that just don't play
nicely together.


John Doty          "You can't confuse me, that's my job."
MIT-related mail:                       jpd@xxxxxxxxxxxxx
Other mail:                             jpd@xxxxxxxxxxxxx