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

Re: gEDA-user: Hierarchy viewer and database proposal



Bill,

> Ok, I wont rewrite anything that exists.  Right now, I need solid=20
> hierarchical netlisting.  I read through some of the gnetlist code.=20
>  It's nicely written.  However, it's missing the data structures I'm use=20
> to for netlist manipulation, and I feel that makes it much harder to=20
> work with the data.
> 
> Here's a quick one-liner about each class in the database schema:

[ . . . .  snip!  . . . .]

The datastructure you propose to accomplish your goal is nice.
HOwever, I am still a little confused about what the prog does.  Note
that I am not an ASIC guru.  Here are my questions:

*  Where does your tool fit into the flow?  After gschem but before
gnetlist?  If so, how is hierarchy determined from the .sch files?
Or is it bolted onto the side of gschem?  In that case, is hierarchy
info also stored into the .sch files?  Or is it an extension of
gnetlist?  If so, how can one use it to view hierarchy?

*  What does the UI look like?  Is it an add-on to gschem which
enhances your ability to follow nets through hierarchy?  Or is the UI
something totally different?

*  As for DRC capability, what are the desired errors to search for?
Carlos's has most of the biggies, it seem to me.  (Again, I am not an
ASIC guru, so I may be missing something important.)

> To make a long story shorter, I think it's a bad idea to ever loose=20
> hierarchy info.  The hier class keeps track of the original structure,=20
> even if we've flattened a design.

So my question is then: how to hold hierarchy info when you export the
design as sch + .sym files?  Should it just be
a FILE= attribute in a .sym file pointing to the lower level schematic
block?  Or is there something more to it than that?

Thanks,

Stuart