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

[John Doty <jpd@xxxxxxxxx>]

On Nov 19, 2008, at 7:11 PM, r wrote:

> On Thu, Nov 20, 2008 at 1:09 AM, John Doty <jpd@xxxxxxxxx> 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/
jpd@xxxxxxxxx




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