kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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


Dick