[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA-dev: New diagram (attempt at UML)
Peter Clifton wrote:
> 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;
>>
>
>
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.
> 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