On Nov 19, 2008, at 7:11 PM, r wrote: > On Thu, Nov 20, 2008 at 1:09 AM, John Doty <[EMAIL PROTECTED]> wrote: >> >>> Agreed. I didn't mean gnetlist doesn't work with hierarchical >>> designs >>> at all - it just didn't produce any useful results last time I tried >>> it. >> >> You haven't clearly stated what your problem was. I've done both >> hierarchical VLSI designs (SPICE style: generate a hierarchical >> netlist with a Makefile and let the downstream tools flatten it), and >> circuit boards (use source= and let gnetlist do the flattening). >> Works great for me. Nobody can fix a problem you can't clearly >> articulate. > > Can you explain in detail how do you generate the hierarchical > netlist?
Here's a simplified version of my current flow. 1. Don't use source= in your symbols. Prepare schematics and symbols according to http://www.brorson.com/gEDA/SPICE/t1.html. 2. Put a list of the component subcircuits in the makefile: SUBCIRCUITS= foo.cir bar.cir ... Note that I import some subcircuits from OpenIP (http:// research.kek.jp/people/ikeda/openIP/) as SPICE netlists: as there are already schematics in the OpenIP documentation there I don't redraw them in gschem. Just put the imported subcircuit netlists in the project directory: if there's no explicit rule to create them and no .sch file for them, make will be content to use them as is. 3. A macro for gnetlist is handy: GNET= gnetlist -q -g spice-sdb -I --nomunge -o $@ $^ 4. A generic rule for netlisting single page schematics is handy: %.cir : %.sch $(GNET) 5. For multipage schematics the generic rule won't work, need to make an explicit rule, but it's easy: foo.cir : foo.1.sch foo.2.sch $(GNET) 6. The hierarchical netlist is then just the concatenation of the subcircuit netlists, so one more rule makes it: project.cir : $(SUBCIRCUITS) cat $(SUBCIRCUITS) >project.cir So now, I can type "make project.cir" and get a hierarchical netlist. > Although using Makefile doesn't seem particularly appealing > to me (I keep all my design data in a single place - schematics) Huh? Schematics are a graphical representation of a netlist. There is so much more that goes into a design. Requirements, high level simulation and optimization code, descriptive documentation, etc. Even for netlists, schematics are sometimes a second-rate representation. A drawing of a backplane that has nothing but a bunch of 100 pin connectors on it is pretty useless, but connector pinlists are nice "source files" both for netlists and text documentation. > it > could potentially make the flow working until the "proper" netlister > is done. > >>> I've looked into the scheme code but I couldn't find any obvious >>> errors. This single error broke my workflow, I think it is important >>> enough to inform others that they should not rely on this particular >>> feature. >> >> What error? > > We discussed several issues here: > http://archives.seul.org/geda/user/Jan-2008/msg00249.html > > Please accept my appologies if those have already been fixed - I > haven't used gnetlist since that time. Let me address the first one: > Is it possible to setup gnetlist (gnetlist -g spice-sdb) so that it > won't add ".END" at the end of the spice netlist? Yes. Make your schematic a subcircuit. Or use. "sed -e '$d'". > > In my flow, I usually prepare a testbench file manually and from here > I include a (clean, without simulation commands) netlist. However, > that ".END" makes this flow awkward. Sure, I can do it the other way > around or postprocess the netlist but it's an additional hassle. It's a *trivial* hassle. It's like the engineer who wouldn't use the signal generator because its output was a type N, and he would only use BNC's. Get over it. Get an adapter. gEDA is an extremely flexible toolkit, adaptable to many flows. It's your job to do the tiny amount of thinking needed to adapt it to *your* flow. The alternative is something too inflexible to adapt at all. But with gEDA, as with many good things, a little resourcefulness goes a long way. 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
