kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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

A pin_group is graphically challenged.  It wants to be seen, but allowing it
to be seen means the pins within it probably should not be seen also.

So then you have think through what might be done to any wires that might
already be in place tied to pins within a pin_group, and now you want those
to go away, in favor of a single wire for the entire pin_group.  This calls
for a powerful, complex editor.

If we can at least identify the pin_group as the best way of eventually
handling this, then it can be postponed, and the current notion of pin is
not disrupted by it, yet.

Dick