kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 3/24/2011 9:37 AM, Dick Hollenbeck wrote:
> On 03/23/2011 04:59 PM, Dick Hollenbeck wrote:
>>>> Pin name is, in fact, actually a pin description, and currently is just a comment.
>>>>
>>>> About pin "numbers" (currently a 4 characters identifier) I believe an enhancement in Eeschema could be the support of pins having 
>>>> multiple pin numbers.
>>>> I see 2 cases:
>>>> -Power pins in large ICs:
>>>>   they have 100 or more GND, VCC .. pins.
>>>>   In schematic an enhancement could be: put only one pin having one pin name (or description) and a lot of pin numbers.
>>>> -"Bus pins"
>>>>   The is in fact a similar case: one pin having many pin numbers.
>>>>   Useful for components like memories and microprocessors to handle data bus and address bus with only 2 pins.
>>>> the difference between these pins is mainly for netlist generation.
>>>>
>>>> In library files format and load/save functions, just allow the ability to store more than one pin number per pin.
>>>> The cost is low.
>>> Thanks for the clarification and out of the box idea on bus/pins.  We can
>>> spend a few emails embellishing the idea.
>>>
>>>
>>> If I tie two such pins together with one wire, and these two bus-pins are on
>>> two different chips, what ensures that the two pins hold all the same pin
>>> numbers?  What if the second bus-pin only has 90% of the pin numbers in it? 
>>> Do we have to have a public "class-definition" system for bus-pins?   Must
>>> the two pins have all the same pin numbers in order to be tied together?
>>>
>> I think another way to achieve this without losing the electrical
>> directionality of each pin, is to support something like a pin_group.
>> A pin_group is a more general term for a bus.  It could be simply a
>> collection of pins within a part.  So the pin_group is a conceptual
>> container of pin names only.  The actual pins are held perhaps in a
>> different container within the part.  A part could have more than one
>> pin_group.  Not all pins need be in a pin_group.
> 
> 
> Here's another idea to consider, slightly different.  In reference to an
> industrial electrical pipe holding many wires, perhaps unrelated to each
> other (and therefore the term 'bus' is not optimal for this use), a good
> name for this might be "conduit".
> 
> 
> Then this alternative uses the term conduit instead of pin_group or bus.  A
> conduit is a container of signal names rather than pin names, and it exists
> in a "conduit registry" within the schematic, available for all to see.  I
> suppose another name for signal is net.  (Hold net_group as a back up
> candidate term.)
> 
> If the schematic editor would let you work by conduit or by wire, then you
> could connect your parts up with single conduits, as long as you stuffed
> those conduits with compatible wires/signals/nets.
> 
> Lets imagine what has to happen as a conduit is brought into a part using a
> mouse drag, just as the part is entered with the mouse pointer, extending
> the end of the conduit up to the part.  Remember, the conduit is defined by
> a set of signals.  
> 
> What does that algorithm look like?  Let's ask what information has to be
> available within the part to allow this conduit to magically connect all its
> signals to the correct pins.  There has to be a match on the signal names
> within the conduit to something in the pins.
> 
> 
> Can anyone take it from here, and imagine if this is practical?
> 
> And how this impacts my original question about the pin attributes in the
> new design, which currently are:
> 
> 1) number and
> 2) name
> 
> I still think improvements can be made to number and name.  Firstly, a pin
> number which allows letters in it can be confusing, I thought a number
> excluded letters.   'Name' would be better for that use.
> 
> So I ask for feedback on changing from -> to
> 
> number -> name
> name   -> net or signal

This seems logical to me.  I personally think "signal" more descriptive than
"net".  However, "net" is such a common metaphor in schematic and PCB editors
that the term "signal" may be less obvious to users.

Wayne

> 
> 
> Dick
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>