Re: gEDA-user: Some kind of library manager and hierarchical netlisting

[John Doty <jpd@xxxxxxxxx>]

On Nov 20, 2008, at 4:07 PM, r wrote:

> On Thu, Nov 20, 2008 at 6:33 PM, John Doty <jpd@xxxxxxxxx> 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/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user