Re: gEDA-user: Hierarchy vs spice-sdb

[sdb@xxxxxxxxxx (Stuart Brorson)]

I can comment in greater detail on this later, but for now a few
notes. 

Yes, spice-sdb implements hierarchy completely differently than the
usual gschem "source" attribute.  There are two reasons for this:

1.  I didn't know about the "source" attribute -- much less understand
it -- when I first did spice-sdb.  Looking back, I might do things
differently now.  But then again, maybe not.  The jury is out.

2.  The purpose of spice-sdb was to enable you to draw schematics and
embedd vendor SPICE models into your netlist.  You need to pay close
attention to the order in which the pins are emitted by spice-sdb in
order to properly match up the pins with the ordering in the .subckt
card.  Therefore, I created a method to explicitly control the pin
ordering of both the upper and lower hierarchical blocks.  The upper
level is pinseq, and the lower level was the spice-IO pins. 

(When you have only a vendor's SPICE model you don't need the lower
level spice-IO pins, but you still need to explicitly control the
emission order of the pins.  More on this below.)

As for the spice-IO pins, they were my lame way to implement hierarchy
before I understood the "source" attribute.  (Actually, I still don't
understnad the "source" attribute . . . . .)  The nice thing about the
spice-IO pins is that they work, and make it crystal clear in your
schematic which order the pins should be emitted in.  I don't know how
one can do this using "source", if at all.

As for the docs, yes, they are old.  And I don't say anything about
"source" because I didn't know about it back then.

About the pin emission order:  The problem is that a classical opamp
has pin numbers:

in- = 2
in+ = 3
VCC = 7
VEE = 4
out = 6

However, the typical opamp .subckt calls the pins out in this order:

* Node assignments
*              non-inverting input
*              | inverting input
*              | | positive supply
*              | | |  negative supply
*              | | |  |  output
*              | | |  |  |
.SUBCKT OP27G  1 2 99 50 39

(That is, in- = 1, in+ = 2, VCC = 3, VEE = 4, out = 5).

Therefore, I couldn't use the "pinnumber" attribute for SPICE.
"Pinlabel" is manifestly not the right attrib to capture this
information.  Therefore, I decided arbitrarily to use "pinseq" since
it seemed to be 
the right attrib for this kind of thing: i.e. it wasn't used for
anything else.  Today, I might chose to use a special attrib for this
purpose, say "pinseq-spice", or somethign like that.   

Eventually, if/when gattrib has the ability to edit pin attributes,
dealing with the pinseq attrib will even easier than it is now.

As for global nets in hierachy, well, I believe that hierarchy in
general isn't properly implemented in gnetlist.  (Hmmm, must put that
into wiki.)  If proper handling of hierarchy is important, perhaps you
should have a look at gnetman, a hierarchical netlister contributed by
Bill Cox a year or two ago.  I believe that it handles SPICE hierarchy
the right way: by leaving the subblock as a .subckt, instead of
flattening the netlist.  Unfortunately, gnetman has been laying
dormant ever since he contributed it.  It is crying out to be adopted
and further developed by some intrepid soul.

About the conflict between how "soruce" handles hierarchy and how
spice-sdb handles it: I'd say that the only advantage to using the
"source" attrib is that you can double click on a block and open it
down.  Besides that, "source" doesn't necessarily do the right thing
(i.e. it just spits out a flat netlist -- if it works at all),
or at least I don't understand how it is supposed to work [1].
The issue is that "source" (and hierarchy in general) is kind of at
the ragged end of gEDA's architectural development, and needs further
work.  Until then, spice-sdb and spice-IO pins are the way to go.
IMO. 

BTW:  I have an example of a hierarchical design in one of the
distributed example files.  It shows how you can generate your
hierarchical netlist with a Makefile, a feature I like a lot.  I don't
know how one would do this using "source" hierarchy instead of
"spice-sdb" hierarchy, except if you accepted that the output would be
a flat netlist.  (Or somebody spent a lot of time hacking gnetlist.)

Stuart


[1]  Please flame me if I am wrong.  

> 
> 
> 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
> 
> 
>