Paul Bunyk wrote:
[flat output of gnetlist]This can be a hard thing to understand. Sometimes hard to debug too, because sub-blocks get re-used byt other designers, and the naming of signals in the hiereachy is not consistent... A(31:0) here, ADDR(32:1) there... Occasionally the only way to sort it out is to look at the flattend netlist, but that's an altogether different topic... ;-)<SNIP>
> >>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 gnetlistVHDL and Verilog have their own ideas about hierarchy, you can instantiate sub designs without too much pain. There are also mechanisms to include multiple files in the simulator/synthesis tool. So, the way I usually deal with this w.r.t. gnetlist is to create standalone multi page schematics for each block, then netlist each group into separate Verilog file, then I use the simulator and synthesis tool to link together the resulting netlists. The parts instantiate each other, as well as hand coded HDL for stuff like state machines... The answer is that, at least for me, I dodge the whole flatten the netlist debate and think of each block as a standalone entity...
> (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...
Being able to `draw a schematic' from scratch would certainly be a nice thing to be able to do in geda. The only piece that is currently missing is some C glue code that wraps and exports the drawing primitives from libgeda into the scheme interpreter...> 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!
-- -------------------------------------------------- Mike Jarabek FPGA/ASIC Designer http://www.istop.com/~mjarabek --------------------------------------------------