gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)

[Bill Gatliff <bgat@xxxxxxxxxxxxxxx>]

Dave N6NZ wrote:

> I believe this style leads to the most readable schematics, and scales 
> up well to larger designs.
>   

Agreed.  At least until you do like me, and forget to put down the power
symbol once (or twice).  :)

At the risk of going OT, I'll add that as I get better at following the
above strategy--- which is particularly helpful with more complex parts
like microcontrollers--- I get really frustrated at gschem's strong
association between pin numbers on the symbol, and pin numbers on the
footprint.  That's just... wrong.  It would be nice if there was an
additional "layer of abstraction" somewhere between the symbol and
footprint, such that actual pin assignments weren't made until the
footprint (and slot, if necessary) were specified.  Until that point, it
doesn't really matter anyway.

For example, I once merely changed the footprint= parameter in a MOSFET
symbol, from to92 to sot23, and found out the Hard Way that doesn't
work.  I think it should.

As a "mostly software" guy, I think about schematic capture the way I
think about C code: it's a specification for signal/data/control flow
only, and the underlying details about how the physical machine
implements that specification take place later.  When you tie physical
pin numbers into the symbol, however, you lose the advantage that a
schematic capture exercise is supposed to provide you in the first
place: the ability to think at a level above the hardware.

The solution might be to get rid of physical pin numbers in symbols
entirely, and replace them with "virtual pin numbers" that map to
physical pin numbers in some intermediate processing step.  For example,
a 7400 symbol might have pin "numbers" A, B, and Y, and then our DIP16
footprint would have pin "numbers" A.1, B.1, and Y.1, A.2, B.2, Y.2,
etc.  When the user specified the footprint=DIP16 and slot=2, then an
intermediate step could "bind" the pins from the symbol to the pins on
the footprint automatically.  (And once that binding took place, gschem
could report the physical pin numbers on the schematic as an option).

Later on, if I swapped the 7400LS/DIP16 package out for a
LittleLogic/SOT5, that footprint would also have A.1/B.1/Y.1 pin
numbers, so gaf would know how to re-bind the virtual pins from the
symbol to the right places.

Ok, if you have been paying attention so far, you'd probably be getting
ready to say that all the above isn't really the right solution to the
problem either.  But if you've followed me this far--- and I thank you
for doing so!--- then you'll get where I'm going next and why.  :)

Packages like SOT5 and DIP16 are used everywhere, not just for
LittleLogic and 7400.  So just going to a "virtual pin naming
convention" that's 7400-specific, like I just described, doesn't really
solve any problems--- it just moves them around a bit.  What is REALLY
needed is for footprints to use physical pin numbers as they do today,
and then use a table (probably carried with the symbol) that does the
ABY->pin mapping on a per-footprint basis.  Something like this:

footprint=DIP14
vpin    ppin
A.1      1
B.1      2
Y.1      3
A.2      4
B.2      5
Y.2      6
GND   7
...
VCC   14

footprint=SOT6
vpin   ppin
A.1      1
B.1      2
Y.1      4
GND   3
VCC   5

The above would likely be highly-redundant, at least for 7400-series
parts, so maybe they could be placed in a "footprinttable=7400.fpm"
file, or something.  When there were exceptions, then the table provided
with the symbol would overrule.

A side-effect of the above is that it lets you have exactly one NAND
symbol, regardless of the footprint of the device the user ultimately
chooses.  It also lets you have only one DIP16 footprint for all users
of that footprint.  And one ATtiny44 in-circuit-programming connector
symbol that works with all the different footprints that microcontroller
comes in, even though the pin assignments are different--- because the
tools can sort out where the wires should go once you indicate the
footprint to use.  And MOSFETS... and so on.

I think the above solution is pretty compelling, and it isn't a big step
away from what we have today.  It's just an additional layer of
abstraction above/replacing the slotdef= parameter.  I'm hardly the guy
to talk about how hard it would be to implement, but it doesn't seem
THAT hard...  :)



b.g.

-- 
Bill Gatliff
bgat@xxxxxxxxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user