gEDA-dev: gnetman inspired libgeda datastructures

[Stuart Brorson]

On Tue, 20 Mar 2007, Peter Clifton wrote:

> Dear all,
>
> Please take a look at the attached diagram for what could potentially
> represent internal data structure for a libgeda which supports
> concurrent netlist updates. This is still very conceptual at this stage,
> and we welcome others input.

Thank you for looking at this!  The ideas involved here are above my
head, but I'm really glad that some smart and energetic people are
actually pushing forward with this project.  It's an awesome
demonstration of the power of open-source development!

Here are some of my thoughts, in random order:

*  Perhaps there needs to be a class/struct called attrib?  An
attribute is different from just a text blob since it is attached to a
component, net, or pin, and conveys information sensible to the
netlister about that component, net, or pin.  Or how do you handle
attributes in this scheme?

*  I have no idea how port & mport work, or what the difference is
between the two, but I assume that's my problem....

*  Ditto for symbol/page.

*  Backannotation.  When e.g. an eco list is read by one of our tools,
what gets updated?  Are provisions in place to handle this i.e. by
overwriting information contained in a (static) .sym file, or some
other method?

*  VHDL:  I tend to favor keeping gschem's file format like it is,
rather than embarking on a radical overhaul like changing to a
VHDL-like format.  I'd prefer to see gschem's file format tweaked to
support hierarchy (achievable by, for example, using {} when
appropriate I think).  The important thing here is that we retain the
ability to read legacy schematics.

HOwever, it does make me think:  Moving
forward, it would be nice to support designs where a schematic
page might contain nothing more than 
[pcb_netname:pinnumber:verilog_netname] 3-tuples
to represent a portion of an FPGA.  I think lots of people are moving
in this direction, since it is silly to draw large boxes with lots of
pins just to represent logic.  Does such a concept fit into this
scheme?

*  The concept of a component (an "object" in libgeda parlance) --
where does that fit in here?  Is a component "graphics"?  Is there a
need to distinguish between a pure graphical object (e.g. titleblock)
and a component object (e.g. a transistor)?

These are just the things which occurred to me while looking at your
drawing this afternoon.....

Excited to see all the new ideas,

Stuart