Unification of Methods and Functions

[Corey Coughlin]

You know, it's interesting, I'm an engineer at a semiconductor
company, and I've written netlist manipulation objects over and over
again with only the most basic oop structure, and they usually work
fine.  Associating data with each cell is usually not that hard,
although the show() function showing data from all cells above it (?)
seems kind of strange.  This type of problem is a case where object
encapsulation is usually a lot more effective than inheritance.  In my
netlist objects, the most basic object is just a name object, which
everything inherits because everything in a netlist has a name. 
Beyond that, there's some container inheritance, I came up with an
ordered dictionary for pin data, some simple inheritance where Pin
objects inherit from Net objects, but that's about it.

The basic object structure is pretty simple.  The highest level object
is a netlist.  The netlist contains a list (just a simple python list)
of cell objects.  The cell objects contain a list of nets, a list of
pins, and a list of instances.  There are classes for instances, nets,
and pins (which inherit from nets).  The instances do refer to their
parent cells, and the pins from the parent are copied in, but that's
about as complicated as things get in the class hierarchy.  There's
also a special container class to describe the connections in a cell,
so I can send the connection mesh a net, an instance, or an
instance,pin tuple, and find out what it's connected to.  That's
probably the most complicated class, since it uses a few internal
dicts and a type driven interface to resolve the input data.  But
that's really about the size of it.  Transistors would be instances in
cells (although a transistor cell parent is also in there) and gates
would simply be cells.  Now if you had similar cells with different
current or power characteristics, I suppose you'd need to associate
those with an instance class instead of a cell class.  Beyond that, I
don't really see why this is such a difficult thing to do.  Unless
there's some other overriding goal this needs to accomplish that isn't
in the spec below.  You might want to try just coming up with
something like the container hierarchy I have, not worrying about
inheritance, and see if that does the trick for you.




Greg Ewing <greg at cosc.canterbury.ac.nz> wrote in message news:<2gip0dF3ffrjU1 at uni-berlin.de>...
> David MacQuigg wrote:
> > 1) We need to represent a hierarchy of cells, typically 5 to 10 levels
> > deep.
> > 2) Each cell has data associated with it.  Some of this data is a
> > cummulative total of similar data from all subcells -- total currents,
> > total chip area, etc.
> > 3) The data for each cell is unique, and it must be displayed in a
> > format unique to that cell.
> > 4) We need a simple function, show() that can be called for any cell
> > or no cell at all (just knowing the cell type).  This function should
> > show the cell data and the data from all cells above it.  In case no
> > cells of a particular type have been added to the design, the
> > cummulative data should just show a default value, like zero.
> 
> It's still not clear whether the hierarchy you're talking
> about is a hierarchy of *kinds* of cells (i.e. a class
> hierarchy), or a physical hierarchy of actual cells (i.e.
> an instance hierarchy).
> 
> Both of these hierarchies can exist at the same time, and
> they are different.
> 
> For example, you might have a kind of cell called NandGate,
> and a kind of cell called Transistor. An instance of NandGate
> contains instances of Transistor -- this is an instance
> hierarchy. But Transistor is not a subclass of NandGate --
> that would imply a Transistor is a kind of NandGate, which
> is not true.
> 
> On the other hand, NandGate may well be a subclass of Gate,
> and Gate and Transistor may be subclasses of Component. But
> that doesn't mean Gates *contain* NandGates.
> 
> If prototype-based programming leads to confusion between
> class hierarchies and instance hierarchies, the I would
> say it's not helpful.