Re: gEDA-user: Hierarchy viewer and database proposal

[Bill Cox <bill@viasic.com>]

Stuart Brorson wrote:
...

> > I'd like to build a commercial quality netlist database into the gEDA 
> > system.  In particular, it would read the .sch and .sym files as 
> > gnetlist does, but it would build a traditional netlist database from 
> > it.  
> >    
> I worry when I hear proposals about holding the design in a database,
> because that implies (at least to me) either a SQL database, or a
> large, indecipherable binary file (e.g. Allegro board file).  In
> either case, accessing the data outside the tool which created it is a
> PITA, which I feel is a bad thing.  I like to write scripts to
> manipulate and check my design files; this is particularly easy if the
> design is held in a standard, ASCII file.    
> My preference is for all design files to be held as ASCII.  If some
> kind of logical grouping for different types of design information is
> desired, I am in favor of using unix directories, which is what the
> old Mentor Design Architect (schematic capture) did.
>  
There's no SQL database involved.  It's just in-memory data structures 
optimized for netlist manipulation.  Some people don't call that a 
database, but it's useful to have a name for it.  Don't worry.  I'm not 
suggesting a Dilbert style database that will just waste people's time. 
It's bare bones and designed for netlist manipulation.  I've attached a 
schema diagram showing the various classes and how they relate.

I also am a fan of ASCII.  Kudos to the gEDA guys for getting this 
right.  My netlist database wont have any save format.  Instead, it will 
be built from the source files, and then tools will run, just as in 
gnetlist.  There's no need for new formats at all, at least not until 
there's a need to capture design data that currently can't be expressed.

> > Guile commands would be added for traversing and manipulating the 
> > data in this database, although I'll write my netlisters in C.  The 
> > kinds of tools this would help enable include:
> >
> > - DRC checking on the netlist, such as floating inputs, shorted outputs, 
> > or attribute errors
> > - Improved hierarchical netlisting
> >    
> Well, I certainly don't want to rain on anybody's parade.  And you
> seem to have a lot of valuable knowledge and desire to contribute!
> Again, if I had my druthers, I would make the "database" be text files
> in unix directories.  Also, I would try to
> extend the current gschem paradigm (i.e. one text file per schematic
> page) rather than re-invent it as something like a whole, new
> database.  The reasons are twofold: 
> 1.  I always want the option of writing Perl or Python scripts to mung
> the design from the command line. 
> 2.  Evolving a working paradigm is usually more successful than
> re-inventing everything afresh.  
> As you might imagine, I am not a fan of large, all-encompassing design
> environments which promise to do everything for you through a single
> dashboard -- they usually trap you in situations where you can't get to
> the data you need to do the (simple) thing you want!  I prefer smaller
> programs which accomplish single design tasks and exchange the design
> info via easily-processable text files.   
> By the way, this means that the design tool interfaces (i.e. the text
> files) need to be particularly well architected.  YOu can hide all
> kinds of horrors in a single database file if only one tool can access
> it.  
>  
I agree.  Small ASCII files are nice.  Big all-encompassing tools are a 
pain.  The current ASCII data formats look good to me.  It would be hard 
to be simpler.
...

> An aside:   One thing I have often dreamed about doing is creating a
> program which reads a digital design captured in a bunch of Verilog
> files, figures out the module hierarchy, creates a tree
> representation of the hierarchy, and then outputs a
> hierarchical schematic (showing the modules as rectangles) which you
> can browse using gschem.   This would help in those cases where you
> are handed a 1/2-completed project, and you've got to finish it.
>
> Improving hierarchy handling in gEDA -- as you are proposing -- is the
> first step to realizing this dream.
>  
This is totally doable.  Schematic generation is a fun project. 
However, it's not a small project.  If there's interest in such a beast 
out there, I'd be happy to help.  In fact, if one of you guys does the 
placer, I'll do a nice router.  Such a router could also be leveraged to 
improve editing schematics.  After moving objects, wires could be 
automatically rerouted in rectilinear fashion.

Thanks for the offer of help.  I'm sure I'll need some.

Bill