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

[Peter Clifton <pcjc2-at-NOSPAMcam_dot_ac_dot_uk>]

On Thu, 2007-03-22 at 07:13 -0800, Steve Meier wrote:

Ooops, hit send before I'd got all the points covered.

[snip]

> > 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.
> >
> >   
> If should be obvious that I am already doing hierarchical buses. Am I
> doing them efficiently? Who knows the structures I am showing are what I
> am using though.

I'm being dense I'm afraid. The kind of explanation I was getting at was
more along the lines of how the user sees buses, what they can do with
them. Must they be homogeneous etc.. I'll try to infer this from the
data-structures you posted.

> net_name_has_priority tells me that the net was specificaly named at the
> schematic level. If it isn't named specifically then the net lister has
> to make up its own name.
> 
> so net_name_has_priority just tells me if the netlister created the net
> name or the engineer.

Ok, that sounds useful.

> net_has_hierarchy_io_pins and net_has_busripper_pins are just an attempt at reducing the time it takes to do searches through various lists. If a net lacks a hierarchy_io_pin then it is a net that only exists in the current level or deeper. I don't have to worry about trying to connect it to the next higher level.

Ok.
   
> >>   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.
> >
> >   
> net_level and bus_level are again attempts to reduce the search times
> through lists

Ok.

> >>   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).
   
> struct st_conn {
>   PIN_TYPE   type;   // Bus or net connection
>   POINT *location;   // x, y coord of the connection
>   BOOL  has_busripper;
> 
>   GList *pins;       // List of pin objects connected at this point
> *OBJECT of obj_type == OBJ_PIN
>                      // the pin is expected to know who its parent is
>   GList *segments;   // List of bus or net segment objects connected at
> this point
> };

> This is probably the main difference. Connections are just used
> temporarily when I am collecting nets and buses at the schematic level.

> Collect connections between segements
> For each segment ask a complex oject for a list of connections which
> will contain pins for each segment.
> 
> //-------------------------------------------------------------------
> // return a list of CONN pointers - one for each pin connected to the
> net or bus segment
> GList *o_complex_pin_connections(COMPLEX *this_complex, OBJECT
> *segment_object, PIN_TYPE pin_type);
> 
> I want to know which segments of type net are connected to each other.
> which of these are connected to pins. After I have a list of connections
> that make up a net I then construct the net. In my view a net knows what
> pins are connected to it and I expect those pins to know who their
> parents are. 

This connection discovery is still important in any system which has
inbuilt understanding of the netlist. The user might draw net-segments
which don't connect to anything, so we need some way to track their
connectivity before they do. Perhaps it is similar to keeping a
temporary net for the new unconnected pieces, and merging with other
nets as they become connected.

My view isn't too different - it just considers "ports" as non-graphical
objects which are connection points between circuits. We can have a
netlist purely generated as a text file if so desired. It is also
necessary that the program can keep track of the relation between this
electrical netlist and any graphical elements drawn to represent it.

> >> // 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

Can I have a bus made up of some other buses?

Do those buses have to be of identical type, or can I bundle my Address
bus and my Data bus into an outer bus representing the physical IO
cable?

Do we mean different things when we speak of hierarchical buses?

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



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