gEDA-dev: gnetman inspired libgeda datastructures
Peter Clifton
pcjc2 at cam.ac.uk
Wed Mar 21 12:30:00 EDT 2007
On Tue, 2007-03-20 at 21:41 -0400, Stuart Brorson wrote:
[snip]
Hi Stuart - thanks for your comments. That diagram is pretty opaque
unfortunately. I need to learn some subset of UML (or add the 1<->many
annotations) to make it clearer.
> 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?
The white-board has little asterisks against things which could have
attributes attached. It was thought that these could be attached (linked
list?) to objects such as "net" and "circuit" etc.
> * I have no idea how port & mport work, or what the difference is
> between the two, but I assume that's my problem....
mport (master port) defines the external connectivity to a circuit
block. (Or the current symbol concept - which is just a special case of
circuit). For example - this is like the prototype in VHDL which
specifies what connections an entity has.
As these "circuits" are instantiable, the net list can't link to the
Mports. Instead, each "Mport" is referenced by a "port" struct for each
instantiated version of the circuit. The "port" struct also retains a
link to the relevant instance of the circuit.
> * Ditto for symbol/page.
Considering a "circuit" to be an electrical black box defined by its
"Mport"s is very similar to what a symbol does presently. A symbol
contains a single page human relevant graphical representation of the
circuit block (e.g. FPGA, opamp).
Alternatively, you can have multiple pages of graphical representation
which are, more conventionally, a schematic. Perhaps missing from the
diagram is the arrow indicating that a certain type of graphic object
"complex" (keeping the present terminology), points to the symbol
representation for another object in the design.
> * 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?
I feel that this is one of the beauties of allowing gschem to understand
connectivity. It should be possible to make a change in PCB, and have
gschem visually represent the changes - e.g. ratlines, where
connectivity is different. (It would also have to strike out or identify
graphical schematic connections which have been broken in the layout)
> * 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.
I don't want to write the interface for VHDL as the file format. I do
concede that its entity description matches well with electrical
sub-circuits.
> 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?
This is possible. Just define the electrical connectivity, which will be
read in from your VHDL or whatever, and don't bother drawing the
schematic representation of it. It will allow the netlister to read in
non-schematic entries.
(This is the converse of an experience I had with Xilinx FPGA tools,
where I had to convert schematics in the Xilinx tools which plumbed
together blocks of VHDL code, into plain VHDL for use with ghdl).
> * 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)?
It is possible. Such graphics are just "owned" by the page, and don't
have any electrical definition. The proposed structure has symbols as
purely graphical representations of an electrical "black box". Whilst
shown separately as concepts on the diagram, it is possible that they
are the same struct. The special case is that what we think of now as a
symbol should only ever have one page of graphical representation.
An "object" is difficult. In current libgeda terms, it is the "Graphics"
class (and subclasses - many not shown, e.g. lines, arcs etc..) in our
diagram. libgeda doesn't currently know about the rest of diagram.
> These are just the things which occurred to me while looking at your
> drawing this afternoon.....
>
> Excited to see all the new ideas,
It was certainly exciting getting them on the board. A certain "spark"
of understanding hit when realising circuits and symbols are just
black-box representations with some external interface definition.
I think buses have a similar magic to them, but I'm still unsure how to
specify the "signature" of a bus.
E.g. I want to be able to say: LVDS_LINK[0:4] where each of the
LVDS_LINK elements is a bus consisting of two signal connections.
Should it be possible to have a non homogeneous bus - e.g grouping a
wiring harness of non identical wires into a bus - e.g. a "bus"
consisting of data, and power cables - each being defined by their own
bus in turn.
Does this help with the feature request of Alessandro Baretta, on the
user list?:
"the automatic production of cabling diagrams and loop diagrams"
(I don't know what a loop diagram is though).
I think his other points were more related to tying in CAD
representations of parts in his schematic, to a (2D?) CAD package. (A
design flow I've not considered before... but when designing machine
control panels, equivalent to PCB layout.
I've worked on machinery before which had its schematics and layout
diagrams done in Autocad. There is no reason we can't support that
design flow if the symbol and CAD representations were done.
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!)
More information about the geda-dev
mailing list