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.