On Nov 20, 2008, at 4:07 PM, r wrote: > On Thu, Nov 20, 2008 at 6:33 PM, John Doty <[EMAIL PROTECTED]> wrote: >> >>> Can you explain in detail how do you generate the hierarchical >>> netlist? >> >> Here's a simplified version of my current flow. > > Thanks! I'll try it. This method looks pretty good. > >> 1. Don't use source= in your symbols. > > That's bad and good. > > Bad because it disables "hierarchical design support" in gschem (= you > no longer can navigate to subcircuits in gschem).
A trivial inconvenience. One of these days, one of the gnetlist front end gurus will put in a flag disabling hierarchy, and things will be slightly nicer. In the mean time, it's not a blight on my life ;-). > Good because all the > design configuration is stored in only one place (Makefile). > >> 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) > > No problem here. Out of curiosity, what do you use multi-page > schematics for in the IC design? Sometimes the subcircuit's too big for a page, and doesn't factor easily. Sometimes a revision adds stuff that won't fit on the original page, and it isn't worth the trouble to refactor. In one case, netlisting page 1 by itself yields a fixed gain amplifier, netlisting it with page 2 yields a variable gain amplifier. I don't like schematic pages that are difficult to read in letter or A4 format: monster pages get in the way of creating a nice combined documents. > >>> 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. > > I keep all these, except maybe for optimization code, separately from > design data. The only exception is end-user documentation that itself > is a part of the product/design. OK, so how do you create that document? I use make. > >> 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. > > I agree. However, the tools I use at my job, handle such a mixed > design environment quite well. > >> 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. > > I feel I need to explain something. There is nothing wrong with > scripting the design flow. In fact, I do this all the time. However, > scripting is only good at the development stage when people want to > streamline their own "boring" job. Once they are done with this, the > result must be as "self-contained" as possible. That's precisely what scripting achieves. Check out the design sources from the archive, type "make", and get all of the data products. > If there is a build > script used it must be tested, documented etc., because it becomes a > part of the product. Indeed. But if there isn't a script, a manual procedure to do the build must be created, tested, documented, etc. That's more work than a script, and it's more likely to cause trouble down the road. > This Makefile-based flow is not different, > although it's simpler than I expected. > > Finally, there is no magic in netlisting. Exactly. It's the automated creation of a data product from a set of data sources. This is precisely what make is good for. > This, except for drawing > schematics, is a basic function users normally expect from any design > entry tool. But they all expect it to work *differently*, and some complain bitterly if the tool doesn't match their prejudices. The narrow perspectives of the complaints on this forum are amazing. gEDA's strength is flexibility, not pushbutton conformity. > Netlisting the design really is not the place where > Makefile should be _required_. If you're doing a straight schematic to flat netlist flow, it *isn't* required. If you want something trickier, you're going to have to tell the tools exactly what it is you want (they can't read your mind). A makefile is a very good way to communicate this. 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
