> 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
