Re: gEDA-dev: New diagram (attempt at UML)

[Peter Clifton <pcjc2-at-NOSPAMcam_dot_ac_dot_uk>]

On Thu, 2007-03-22 at 05:49 -0800, Steve Meier wrote:
> I think that your netsegment should be a segment that way it can be used
> for both buses and for nets.

That is a nice idea - and something we've considered. As it is a
graphical construct, it doesn't matter whether it is a bus or a net. We
can add flags to make it draw differently as desired by the user, or
automagically - depending on what net / bus it is part of.

When the white-board diagrams are posted, you might see that at one
stage, we tried to consider "net" as a special case of "bus" - as the
lowest atom in a hierarchy.

> Is an mport the same as a connection?

Basically.

> struct st_net {
>   GString *net_name;
>   GString *net_hierarchy;

I'm not sure what this last member was for.

>   GList *other_net_names; // List of gchar strings that represent other
> names for this net
>                           // Use this for joining nets on a page. It
> allows a net to have more
>                           // then one name to support the hidden nets of
> components

>   BOOL net_name_has_priority;
Not sure what this does.

>   BOOL net_has_hierarchy_io_pins;
Not sure what this does.

>   BOOL net_has_busripper_pins;
I'm really not sure how we should do buses "properly". Please let me
know your thoughts on this subject. I'm hoping that we can support
arbitrary nesting of buses within buses.

>   BOOL hidden_net;
This means it isn't present in the schematic?  We don't need this, as
netlist is separate from the NetSegments anyway.

>   int net_level;          // hierarchy depth of this net - number of
> schematics down from the top level

I don't think we want or need this. As you can instantiate a circuit in
any hierarchy level, and the per-circuit netlist is just that "per
circuit", it doesn't have knowledge outside this circuit.

>   GList *pins;            // List of object pointers of type OBJ_PIN to
> complex objects

In the proposed system, instantiated circuit pins are not unique to a
particular instance of a circuit. The diagram's many to one link between
a "pin" and a "net" only refers to pins representing external
connections with this circuit.

The pins on an embedded complex will be referenced indirectly via a
"port", which ties into the circuit instance and a particular Mport. (I
would need to make the arrow between Pin and Mport bidirectional - now
updated on the diagram).

>   GList *busripper_pins;  // List of object pointers of type OBJ_PIN to
> busripper objects
> };

> // A bus is a collection of nets at one hierarchy level
> // Multiple hierarchy level will be created by adjusting the bus name
> // to include the lower level hierarchy_tags

I think it is important to keep names, and data relationships
independent. A likely embodiment is structs in memory, referenced by
pointers and linked lists. If that is the case, they must be navigable
as such.

> struct st_bus {
>   GString *bus_name;
>   GString *bus_hierarchy;
What does bus_hierarchy do?

>   GString *bus_nets;
Is this a string representation of a net?

>   BOOL bus_name_has_priority;
> 
>   BOOL bus_has_hierarchy_io_pins;
> 
>   BOOL bus_has_busripper_pins;
What do the last three of these do?

>   int bus_level;   // hierarchy depth of this bus
> 
>   GList *pins;     // List of object pointers of type OBJ_PIN
> 
>   GList *busripper_pins;     // List of object pointers of type OBJ_PIN
> 
>   GList *nets;     // List of nets connected to this bus - for each bus
> ripper see if it is part of an existing net
>                    // on the current page. If it is add it to that net,
> otherwise start a new net and include the busripper in that net
> 
>   gchar** net_names; // an array of net names in the order they they are
> within the bus as deffined by the bus attribute
> 
>   int net_name_size; // number of strings in net_names
> };

Thanks for your comments - and the struct listings. I think to help make
things clearer regarding our design we should do similar. They will
probably be pseudocode structs with placeholders for the actual object
data (coords etc..) I think the inter-relationships are the most
interesting topic here.


-- 
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!)



_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev