On Dec 22, 2010, at 9:55 PM, Young, Michael I. (DFRC-SR) wrote: > Hello, > I have been playing around with one of the examples given in the > distribution for an RF_Amp in an attempt to learn how to use gschem > with SPICE. I noticed that you don't seem to be able to go down the > schematic tree into the Q1 and Q2 schematics. When I looked inside it > looks like you have to terminate the "ports" on the SPICE subcircuit > with spice-subcircuit-IO-1.sym instead of an in-1.sym or out-1.sym.
For SPICE and other hierarchical netlist formats, you generally do not want to let gEDA flatten the netlist, printed circuit style. Because the hierarchy semantics are in the core code of gnetlist where a Guile back end or plug in has little control, you must use a different approach to hierarchy. The design of gschem/gnetlist is unusually good when it comes to keeping semantics out of the core code, but it's not perfect. So, we have radical flexibility combined with occasional frustrating roadblocks. > I > am guessing that this, as well as no pinlabels in BJT_Model.sym, Lack of pinlabels is no　problem here: gschem (correctly: it's a graphics editor!) ignores the non-graphical semantics of network connections. If it interpreted those semantics, it would get them wrong here. > is why > you can't go into the Q? Schematics. You can't go there because there are no source= attributes associated with the symbols. Leaving those out is one way to prevent the flattening of hierarchy. But it's not the only way. > Is there any way to set this up > so you can drop into the Q? Schematics in gschem? Either put the appropriate source= attributes into the symbols, or attach them at schematic level. To prevent gnetlist from attempting to flatten the hierarchy, put the following line in the gafrc file: (hierarchy-traversal "disabled") John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
