[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

Paul Bunyk wrote: 
[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...

Breaking of numerous netlisters at once is a concern. I've actualy been thinking that you'd call some function or set some flag early in the netlister backend to tell gnetlist to enter into hierarchical mode. Hopefully that would not break all the netlisters at once...

It has been a few years since doing a design for an FPGA in verilog, but it was certainly hierarchical.

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!

One of my big complaints about Skill is I wish cadence would have made up their minds about "is it scheme/lisp or isn't it". It's pretty gross that you can write

x = 3
y = x*6
(setq z (plus x 4))

in 1 file. I want only scheme or only c-like syntax. Not both! My other giant cadence complaint is how !@*#$& hard is a readline-like interface!!! The fact that there still is no reasonable command history, command line editing, command completion, etc in interactive skill sessions in cadence in 2005 is nothing short of totally lame.

In my mind a big place where we could use some extensibility is in gwave. I'd love to have an open source waveform calculator which is extensible. scilab/octave are ok, but they're not really waveform viewers in that they don't have cursors, easy panning/zooming, etc. gwave has the cursors and panning/zooming, but no calculations.

-Dan