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

Re: gEDA-user: Hierarchy viewer and database proposal

Carlos Nieves Onega wrote:
El lun, 20-10-2003 a las 23:17, Bill Cox escribió:

[snip]


The kinds of tools this would help enable include:

- DRC checking on the netlist, such as floating inputs, shorted outputs, or attribute errors

A few months ago I thought geda lacks of a good DRC checker, to check
things like the ones you mention.
Then, I wrote a DRC gnetlist backend, which is now included in gnetlist
distribution as gnet-drc2.scm .
I think it's quite complete, so maybe you want to have a look at it
before writing another one. There's always room for improvement.
...
Ok, I wont rewrite anything that exists. Right now, I need solid hierarchical netlisting. I read through some of the gnetlist code. It's nicely written. However, it's missing the data structures I'm use to for netlist manipulation, and I feel that makes it much harder to work with the data.

Here's a quick one-liner about each class in the database schema:

Design
The top level for a hierarchical structural design. It has a name, and a hash table (by name) of netlists, and a root hierarchy object.

Netlist
This is basically the result of one schematic.

Inst
Netlist instances, some of which represent sub-netlists.

Net
Nets within a schematic.

Port
I/Os of instances.

Mport
Mports (for Master port) describe the I/Os of a netlist. They correspond to flag instances inside the schematic, and ports on instances of the schematic.

Bus
Busses are a simple class that have an array of nets.

Mbus
Mbusses represent I/O busses.

Hier
This class is a somewhat new concept for me. In the past, I've just used the netlist/inst relationships to keep track of the hierarchy. The problem is that the first thing we often do is flatten the design. This results in a few problems. First, names get really long for large designs. They can use up a large portion of the memory. Second, we loose the hierarchy info, which often is needed later. For example, the Altera back-end tools make good use of hierarchy, even if it's uniquified. This means some poor guy has to recreate hierarchy from net names, which is generally buggy. Or, perhaps we want to see the results of synthesis, but want the gates presented in a hierarchy as similar to the original as possible. Another problem is that early on, before flattening, there's no place to put instance attributes. This leads most systems to have some kind of hacked hierarchy object anyway.

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

Bill