[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA-dev: New diagram (attempt at UML)
On Thu, 2007-03-22 at 07:13 -0800, Steve Meier wrote:
> >> struct st_net {
> >> GString *net_name;
> >> GString *net_hierarchy;
> >>
> >
> >
> net_hierarchy? Imagine a schematic that is used twice in a higher
> level. Call this schematic BasicCircuit.sch which has BasicCircuit.sym
>
> put two instances of BasicCircuit.sym in to top.sch provide a refdes of
> S1 for the first instantiation and a refdes for the second S2. Now
> these two instanses are not wired together but they will have the same
> net names within them. net_hierarchy and bus hierarchy are used to avoid
> name space violations. Thus internal nets for the first one become
> S1/Net_01 and nets within the second instansiation become S2/Net_01.
This is required to give a complete netlist of the design. The netlist I
show in the diagram is a per level netlist, not a flattened netlist
(Even if such a netlist retains structured names like S1/Net_01).
I expect there has to be some notion of a path through the design,
traversing by name - such that back-annotation items referred to by
string can be found.
> > 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.
> >
> >
> 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.
>
> 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.
>
> 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.
>
>
>
> >> 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.
> >
> >
> net_level and bus_level are again attempts to reduce the search times
> through lists
>
>
> >> 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.
>
>
> >> 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?
> >
> Good question I see where Iset it but then never use it. The bus_name
> has the representation of the 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.
> >
> >
> >
>
>
>
> _______________________________________________
> geda-dev mailing list
> geda-dev@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
--
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