kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 3/24/2011 9:51 AM, 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.
> 
> What we have now is:
> 
> (pinTYPE SHAPE (at X Y [ANGLE])
> 
> (length LENGTH)
> 
> (name“NAME” (font[FONT] (size HEIGHT WIDTH) [italic] [bold]) (visible YES))
> 
> (number“NUMBER” (font[FONT] (size HEIGHT WIDTH) [italic] [bold])
> 
> (visible YES))
> 
> (visible YES)
> 
> )
> 
> 
> 
> So a 3rd consideration is to do what Jean-Pierre suggested, handling
> multiple (number....) elements.
> 
> Feedback on the 3 ideas is needed at this point. Without feedback I will not
> change anything, since multiple pin 'number's can be added later relatively
> easily.

JPs 3rd idea may be more flexible in terms of assigning net classes.  I'm
thinking of those device packages that have most of their power pins grouped
together except for that odd ball pin or two that ends up somewhere else on the
package.  Even though electrically they may be the same signal, physically
there may be significantly different layout requirements.  I'm not sure this is
a big problem but I can see uses cases were this signal grouping may cause some
issues.

Your comment about them being graphically challenged is probably a bigger issue
than the internal representation.  I'm not sure how to display this concept in
the schematic editor let alone a graphical part file editor.  Are there any
other programs out there that use this concept?  Maybe we could get some ideas
about how and how not to implement this graphically.

Implementation challenges aside, it is a good idea considering the increasing
complexity of modern IC packaging.  If this concept can be defined in a manner
that maintains the readability of the part file format, then it should defined
now even if it is not implement it right away.

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
>