El lun, 20-10-2003 a las 23:17, Bill Cox escribi�: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.
[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. ...
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
