Re: gEDA-user: Hierarchy viewer and database proposal

[Bill Cox <bill@viasic.com>]

Stuart Brorson wrote:

> 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?
>  
The first thing I'm doing is a working hierarchical netlister.  I 
couldn't get gnetlist to do it.  The internal data representation used 
in gnetlist is just a list.  I can do the job more easily with 
traditional hierarchichal data structures.

To enable all the existing netlisters in gnetlist, I'll write out a flat 
netlist for gnetlist to read in.

Viewing the hierarchy could be done as follows:

-- In gschem, run the netlist database to build an internal hierarchical 
representation of the netlist
-- When we push into a sub-schematic, generate a new .sch file that has 
the hierarchical net names from higher level ports, and view that.

There could be other similar functions.

> *  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?
>  
No GUI.  Just command line.  Basically you specify input top level 
schematic, and output netlist.

> *  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.)
>  
I wont reinvent any of the DRC's he's checking.  Does it currently deal 
with hierarchy?  For example, if there are shorted outputs on different 
levels of the schematics, will it be caught?

>  
> > 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
>
>
>  
There will be options for output flat netlists, uniquified netlists, or 
just hierarchical netlists.  The format will be a netlist format, rather 
than sch and sym files.

Bill