Re: gEDA-user: Hierarchy viewer and database proposal

[sdb@cloud9.net (Stuart Brorson)]

> I'm trying to use gschem to design the digital portions of a chip we're 
> building.  The schematic editor looks pretty good.  Gschem has a fine 
> GUI, and it's highly configurable.  However, support for doing complex 
> stuff on a hierarchical designs could be improved.

I second this, opinion about hierarchy.  (Not to slag off gschem,
however, which is wonderful!)

> 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.

> 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.  

> With such a database, a powerful hierarchy viewer mode could easily be 
> added to gschem, although I'm not going to write it.  With such a mode, 
> one could:
> 
> - Highlight and follow signals through the hierarchy in gschem.
> - Build a tree-control for traversing the hierarchy
> ...

This would be wonderful.

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.

> I've written a few such databases in the past while working for 
> QuickLogic, Synplicity, and ViASIC.  I also wrote the original schematic 
> generator in Synplify's Analyst product.  I'm going to write one for 
> gschem for my own hierarchical netlisting and DRC checking purposes.

Wow!  You are an expert!  Welcome to gEDA!  Please let me know if you
need any implementation help.

> Would there be any interest in having this tool in the gEDA suite?

Yes, inasmuch as it is evolutionary, and not revolutionary.

My opinions only,

Stuart