Re: gEDA-user: Hierarchy vs spice-sdb

[John Doty <jpd@xxxxxxxxxxxxx>]

Stuart wrote:

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

I don't think it existed.

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

This mechanism works well. The problem is the incompatibility of this with
the hierarchy mechanisms. I note that the pinseq mechanism allows the
netlister to produce a subcircuit file from the schematic alone, while the
pinlabel mechanism used by hierarchy requires a symbol to make the
connection. It seems therefore cleaner to use your pinseq mechanism (but
it would be better to just have one mechanism, not two).

> As for the spice-IO pins, they were my lame way to implement hierarchy
> before I understood the "source" attribute.

Lame? Don't think so. Been using them with great success.

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

The place where the docs fall down here is in the hierarchy stuff: your
docs are good.

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

I seem to recall that the old SPICE netlist back end did it that way too
(been a few years since I used that, however). It does seem to be the
right mechanism for an existing subcircuit. The only question is whether
it's also good for a subcircuit generated from a schematic. Seems simplest
to say "yes".

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

Yep. I hope they continue to be. They work fine, and gEDA should be
consistent.

> 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 hadn't noticed that, but that's how I've been doing it too. Simulation
Makefile does a  "make subcircuits" in each library directory before
putting together the simulation. The problem is that it all broke when I
started to use source attributes to help navigate. I know, it's like:

Me: Doctor, it hurts when I do this.
Doctor: So don't do that!

;-)

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