If you leave out the source= attribute, and put in a file= attribute,
you can avoid flattening and let SPICE handle hierarchy
with .INCLUDEd subcircuits. The command:
gnetlist -q -g spice-sdb -I -o DPST-NC.hcir DPST-NC.sch Components/
Models/CMOS.sch
created this circuit file:
*******************************
* Begin .SUBCKT model *
* spice-sdb ver 6.12.2005 *
*******************************
.SUBCKT DPST-NC 7 8 9 10 1
.INCLUDE Components/NoqsiIP/Inverter.cir
.INCLUDE Components/NoqsiIP/NOR2.cir
*============== Begin SPICE netlist of main design ============
.LIB 'mm0355v.l' SF
X5 5 1 6 NOR2
X4 4 5 Inverter
X3 3 4 Inverter
M2 9 6 10 VSS nch OFF l=0.4u w=3u
X2 2 3 Inverter
M1 7 6 8 VSS nch OFF l=0.4u w=3u
X1 1 2 Inverter
.ENDS DPST-NC
*******************************
The .INCLUDEs resulted from file= attributes in Inverter.sym and
NOR2.sym. The -I arg to spice-sdb prevents it from including the
subcircuit files itself, allowing SPICE to do it.
The disadvantage is that "Down Schematic" in the Hierarchy menu
doesn't work when you do hierarchy this way, but I don't find it
especially hard to just open the subcircuit schematic from the File
menu.
On May 9, 2006, at 3:07 PM, Dan McMahill wrote:
al davis wrote:
On Saturday 06 May 2006 23:14, Dan McMahill wrote:
I would really like to see true hierarchical support added to
gnetlist. For driving spice or gnucap simulations thats
really the right way to do it.
It makes a big difference to gnucap, and it will become more
important in the future. Spice flattens it anyway, so it doesn't
really matter.
gschem doesn't do hierarchy, so how can gnetlist?
gschem does seem to do hierarchy. I created a symbol "mycell.sym"
and a
schematic "mycell.sch". In the symbol, I added a source=mycell.sch
attribute. Then I created a schematic, top.sch, where I instantiated
mycell.sym 3 times. Then I netlisted with gnetlist and got:
* gnetlist -g spice-sdb -o top.ckt top.sch
*********************************************************
* Spice file generated by gnetlist *
* spice-sdb version 6.12.2005 by SDB -- *
* provides advanced spice netlisting capability. *
* Documentation at http://www.brorson.com/gEDA/SPICE/ *
*********************************************************
*============== Begin SPICE netlist of main design ============
V1 6 0 dc 0 ac 1
X1/C1 6 7 0.1u
X3/R2 3 1 2k
X3/R1 1 3 1k
X2/R2 5 4 2k
C1 0 2 100p
X2/R1 4 5 1k
X3/C1 1 3 0.1u
X1/R2 7 6 2k
X1/R1 6 7 1k
X2/C1 4 5 0.1u
.END
so I see all the elements in there in a flattened fashion. Now, the
fact that the element names won't work in spice is a different
problem.
Also I noted that this isn't wired up the way I have it wired but I
think I just don't have something set correctly on my pins.
The biggest deficiency in gnetlist is that it doesn't properly
translate all symbols. There should be some default rule that
defines how unknown symbols are translated. Something like
everything is a subcircuit (type "X") might be appropriate. I
guess this is another reason why the Spice format must go away.
We should be careful in talking about gnetlist, the core C program, vs
the spice-sdb (or whatever other one), the scheme backend[1].
gnetlist
will process all symbols. It's up to the individual backends to
decide
what to do with them. So the problem you're talking about here is in
the spice-sdb backend, not the gnetlist core.
The problem I see with gnetlist (the core) is it flattens the netlists
so the backends don't have a chance at getting at the hierarchy. Once
that is addressed, we can also try to make the individual backends
(spice-sdb for example) behave in a more desireable way. My take is
what should happen is if you get to the bottom of the hierarchy
(i.e. an
element with only a symbol and no schematic), then you should write it
out as a subcircuit call and it is up to the user to make sure they
have
a library that includes a model for that.
-Dan
[1] For the benefit of those who may not be familiar with gnetlist
internals, there is a core program written in C. It loads the
schematics and creates an internal database of the design. Then it
calls a top level scheme function for the particular netlist
backend. This scheme function comes from the name given in the '-g
netlist-type' flag to gnetlist. At this point each individual
backend (which are written in scheme) has the responsibility of
doing all formatting needed for the output netlist type.
Unfortunately, the gnetlist internal database is already flattened
so the scheme backends have no opportunity for going back and
reconstructing the hierarchy.
I think what is needed is a rewrite of the gnetlist core to build a
database (perhaps using the gnetman schema as a model) which is
hierarchical. To not break all 27 backends at once, we'd need to
perhaps add a flag which would preserve the old behaviour. In fact
some backends might want a flattened database to start with.
John Doty Noqsi Aerospace, Ltd.
[EMAIL PROTECTED]
