gEDA-dev: New diagram (attempt at UML)

[Peter Clifton]

On Wed, 2007-03-21 at 19:43 -0800, Steve Meier wrote:
> Peter,
> 
> For the attributes, the tend to be associated with what is currently an
> OBJECT structure (which is the equivelent of your complex). In my
> version of OBJECT, I establish two lists for attributes. The first are
> attributes which come from a symbol file. The second, are where an
> attribute is added at the schematic level, but still attached to an
> instance of an OBJECT.

Currently the primitives in gschem / libgeda (objects) are graphical. I
wanted to get away from this. It does appear I've left off some possible
entities which can have attributes associated with them though.

In the structure Peter Brett and myself proposed, the "circuit" is king,
not a graphical object. circuits may have attributes (from the
database / file / wherever it came from). There may also be attributes
attached to the instance of a particular circuit.

> This makes it easy for me to ask an OBJECT do you have schematic level
> attribute of "refdes"? what is it's text value? Or do you have a symbol
> level attribute of "net" and what is its value?

We'd wondered about special-casing refdes, as it is pretty fundamenal.
On the other hand - our netlist will work without refdes as necessary.
It just refers to instantiated circuits (by pointer say). A final output
for PCB would need them.

> Pins and Segments (bus or net) can inherit from Line, but a COMPLEX has
> to maintain a list of PINs. In my book as does a Net or a Bus. I also
> have seperated busrippers as a different class from complex objects.
> WHy? well I expect the busripper to have behaviors that I don't expect
> from a complex.

COMPLEX is just a list of embeded graphic objects. (It might not
explicitly link to all of them, perhaps the first in a linked list -
this is an implementation detail).

Say we instantiate 10 OR gates "circuits" in a circuit. The template
representation of this circuit has "Mports" defining its external
connectivity. It also has one "page", a graphical canvas to represent
that circuit block on the screen. That "page" owns a collection of
graphical objects which represent the component.

Some of those graphical objects are pins. A "pin" is a graphical
representation of a circuit's "Mport", and as such, has a link to the
"Mport".

As gschem will need to identify quickly which net a pin / NetSegment
represents connection to, a bidirectional association is made between a
a net and the pins + NetSegments. (Note that our netlist is
hierarchical, and this bidirectional association is _only_ for pins and
NetSegments within our current page. It doesn't cover pins and nets in
nested complex objects.

I'm glad you suggested the need for COMPLEX to have a list of pins, it
was something which we forgot to look at.

We do want to identify where the connecting points are on its periphery.
I think this would be done by associating a link between a circuit
"instance" or the "circuit" and the "complex" which represents it. With
the present diagram, you could enter the complex by following its "prim
objects", and find the pins. That links you back to Mports, but not the
specific instance. (and hence the nets). I'm working on a way round
this.

I haven't got to busrippers yet. You'll see that the diagram lacks
proper bus support. I'd like to have some hierarchical bus support, but
haven't figured out the best way yet.

I'll post a new diagram soon,

Regards,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)