Programming in Gnetman

Anyone interested in working with gnetman to create new netlist maniputlation tools first needs to understand the datastructures. This means working with DataDraw schemas, which is a class diagramming tool used by gnetman.




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

Root
Just a name-based hash table of designs so you can find a design given it's name.

Design
The top level for a hierarchical structural design.  It has a name, and a hash table (by name) of netlists.  Designs point to the root netlist, and also have a name-based hash table of Globals

Globals
Just global nets.  Global nets have a list of local nets in the various netlists that map to them.

Netlist
This is basically the result of one schematic.  There are name based hash tables of nets, instances, and the I/O ports, called Mports (for master port).  Mports can be grouped into bus ports called Mbus, which are also hashed by name.  Nets can be grouped into Bus objects that are also hashed by name.

Inst
Netlist instances, some of which represent sub-netlists.  Instances are inside their owning netlists, but also can have an "Internal" netlist that is the sub-netlist represented by the instance.  Instances have doubly linked lists of their ports.

Net
Nets within a schematic.  They have doubly linked lists of their ports.

Port
I/Os of instances.   These objects are used to connect instances to nets, and will always have an owning mport that has info like the port name on it.

Mport
Mports (for Master port) describe the I/Os of a netlist.  They correspond to flag instances inside the schematic.  A netlist like NAND2 might have a single Mport named Z, but there can be 10,000 instances of the NAND2.  In this case, there will be only one Mport for Z, and that's where the name Z is stored, along with information like whether the port is an input or output.  Each of the 10,000 instances of the NAND2 will be represented with an Inst object, and there will be a Port object on each of them corresponding to the Z mport.

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.