Re: gEDA-user: Introduction and some questions/thoughts on gEDA/gaf...

[Paul Bunyk <pbunyk@xxxxxxxxx>]

[flat output of gnetlist]

Yes, that was the painful lesson that I learned today -- after
figuring out that source=foo
assumes that foo is in a "library" directory, that's it ;-) -- that
gnetlist's netlists are flattened.
It would definitely make more sense to keep hspice hierarchical format
and, if someone
needs to convert that to flat spice netlist, I've written a perl
script to do just that (maybe I
should check it into gEDA after finding it under all the layers of
crud that accumulated over
my magnetic storage media which survived my threee jobs and moves from
NY to CA to
Canada ;-) ). 

> >>Of course in the IC world, hierarchical netlisting is pretty much a
> >>requirement.

That's the world I am in -- I had pretty hard time explaining my problem to our
room temperature electronics (board-level) guys over a cup of coffee last night,
they did not seem to fully grasp the notion of hierarchy... ;-) 

> I need to read up on gnetman and also learn the internals of gnetlist
> (not the scheme backends, but the c program part).  You're right that
> gnetman does hierarchical netlisting, but I want to understand why one
> needs to use that rather than making gnetlist do it. 

Maybe because having those pesky X*s, U*s, etc. in C-gnetlist->scheme 
gnetlist interface would break ALL netlisters simultaneously? ;-) OTOH,
how do VHDL/Verilog/VAMS guys live without hierarchy, do they consider
a piece of VHDL code to load into an FPGA a "single entity"? Just curious...

> I like how easy it is currently to write new gnetlist backends and that you 
> can easily test it out without recompiling.  In fact, you can also ship someone 
> the .scm file and they can use it to without recompiling.

That's the beauty of the approach! Actually, on studying guile more I was
a bit disappointed that it does not seem (at least on my cursory look) the 
notion of _extending_ guile with gEDA stuff, only _embedding_ it  (see this
http://docs.python.org/ext/ext.html if you are totally lost at this
point! ;-) ).

Last time I came across a (Python) program which embedded the interpreter
it took me maybe half a day to convert it into a shared library which
extended it --
with an added advantage that any weird .so or .py can be loaded afterfact
to support whatever script you care to write/run. I see no reason why this
would not benefit this project (after all, scheme is more powerful than tcsh
or make ;-) ), but I do not think (at the moment) guile supports it OOB. 

Dan, I've noticed your "indeed" -- I think that the best part of DFII
is that it is
basically an (almost) stand-alone Skill interpreter with everything (including 
drawing "things" on an empty canvas) implementable in Skill. Next time I get
my hands on an installation, I'll measure exactly how much space .il/.ils/.ctx 
(or whatever the context extension was) files take vs. compiled executable 
code, just for the reference. It IS a lot!

> -Dan

Paul B.