Yes, I said pin mapping - this is something else I think belongs in the gschem->pcb flow. I think a light symbol should have symbolic pin names, like E,B,C for transistors, or A,B,Y for NAND gates. For most box-type symbols (MCUs, memories, etc) the pin label can be used as the name - pins just won't have pin numbers at first. The component database provides a symbolic pin to physical pin mapping, along with pin grouping information. This replaces the slotting information we currently use, but also adds pin swapping, and provides this information to pcb. A future version of pcb may allow the user to swap pins, gates, or chips, and back-annotate that information to gschem. For example, a standard 7400-series quad NAND gate might have this for a pin mapping:

  [(A,B),Y]=([(1,2),3],[(4,5),6],[(9,10),8],[(12,13),11])
  GND=7
  VCC=14

  (D0,D1,D2,D3) = (1,2,3,4)
  (A0,A1,A2,A3,A4,A5,A6,A7) = (5,6,7,9,10,11,12,13)
  WE = 14
  CS = 15
  GND = 8
  VCC = 16

  G = 1
  S = 2
  D = 3

  G = 4
  S = [1,2,3]
  D = [5,6,7,8]

  [G,S,D] = ([1,[2,3],[10,11,12]], [7,[8,9],[4,5,6]])

As for something like a quad latch, which has swappable groups that aren't gates...

  ([A0,Y0],[A1,Y1],[A2,Y2],[A3,Y3]) = ([1,2],[3,4],[5,6],[7,8])
  G = 9
  EN = 10

Note that this spec assumes that a symbol won't have more than one pin for each name. If a component has two pins with the same name, either they're different slots, or they're connected together, like power/ground pins or many-pin power transistors. If a symbol *does* have two pins with the same name, gnetlist will have to make them unique somehow so that the mapping stuff knows which one is which.

Amusingly, this means that those big IC box symbols will only have one ground pin from now on :-)

Syntax Summary

• If it isn't obvious what you mean, it shouldn't be allowed.
• (...) means "use one of"
• [...] means "use all of"

THING = PINS

Maps one thing to one pins (one name to one pin, one group to one group of pins, etc).

THING = [ PINS, PINS, PINS ]

Extra grouping on the right means a one-to-many connection; the net connecting to thing connects to all pins in the right. Note that thing and pins may be groups, in which case you're parallelling gates (like paralleling transistors in an array to increase current limits).

THING = ( PINS, PINS, PINS )

Extra permutations on the right are used for "slotted" symbols, where a device contains multiple copies of the same thing, which are each individually represented by a schematic symbol. Example: 7400 has four NAND gates, THING would have three pins in a group and there would be four PINS, each with three pin numbers.

[ THING, THING, THING ] = [ PINS, PINS, PINS ]

A group of things can be mapped to a group of pins. This is mostly used to create a "thing" and "pins" that can then be further grouped or permuted, but may be used for stylistic reasons too. Pairings are sequential; the first THING is mapped to the first PINS, the second THING to the second PINS, etc.

( THING, THING, THING ) = ( PINS, PINS, PINS )

Permuting on both sides means the THINGs are equivalent, and thus swappable, despite having different names. Like grouping, each THING is mapped to one unique PINS, but the order need not be preserved - the first THING could map to the third PINS, etc. This is used in, for example, swapping bits in a latch (THING is a group of pins) or address lines in an SRAM chip (THING is a single pin).

Note that "swappability" is assigned to the PINS, not the THINGS. Where it can be implied, you may omit the parens on the THINGS. Also, When you combine both pin and gate swapping, you're allowed to define pin swapping on some but not all gates.

[ THING, THING, THING ] = ( [ PINS, PINS, PINs ], [...], [...] )

Here's an example of a group of things which maps to one of a set of groups of pins, like a NAND gate. Here the grouping is inside the permutation - so we're permuting whole gates. Note that the parens are optional if they're top-level, i.e. mapping one THING group to many PINS groups implies the parens.

[ THING, THING, THING ] = [ ( PINS, PINS ), PINS, PINS ]

Here's an example where the grouping is outside the permutation, so we're permuting pins within a gate.

( [...],[...] ) = ( [...], [...] )

So here's an example of a group of things which can be mapped to any of a group of pins. This is for latches and such, where groups of pins (like A0,Y0 vs A3,Y3 etc) need to be swapped as a group.

Syntax Shortcuts

[A,B,Y]=[1,2,3], [4,5,6], [9,10,8], [12,13,11]

Same as [A,B,Y]=([1,2,3],[4,5,6],[9,10,8],[12,13,11]) - mapping one group to many groups means that symbol is like a gate, and can represent any of the gates in the chip. I.e. if there are more things on the right than on the left, top-level parens are assumed on the right.

[(A,B),Y]=[1,2,3], [4,5,6], [9,10,8], [12,13,11]

Same as [A,B,Y]=[(1,2),3], [(4,5),6], [(9,10),8], [(12,13),11] - parens on THINGS are migrated to the corresponding PINS - it's the chip that defines swappability, not the symbol. For most chips, parens on THINGS is easier to manage and does the right thing, but this allows for cases where some gates may not be swappable - for example an MCU with configurable pins on some but not all UARTS, an FPGA where some pins are input-only, or even simpler - a NAND gate where a fast-clocking output must be kept away from a high-impedance input, but only for one gate. Also, by defining swappability on the PINS, we put the information where it's needed for the layout program to do pin swapping.

Power Pins

You'll notice that the power pins are also listed. Figuring out what to do with power pins (or, in general, any "implied" pin connection) is a related problem, especially since the schematic doesn't always know which pins are power pins (it depends on the package, which might be determined later). My idea is that there's a new schematic object that's a table mapping refdes/pin to netlist. Alternately, this could be a CSV imported by the netlister. So if you have a chip U5 with a Vcc pin, there'd be a "U5;Vcc;+3.3v" entry to map that pin (whichever it is) to the +3.3v net. Entries could have lists or regex, such as "U[3-7];Vcc,Vdd;+3.3v"

Note that power pins are not marked as "special" in the syntax - the fact that they don't show up on any symbols in the project is enough to get them listed elsewhere. This also allows for unused gates to show up so that the inputs can be tied high/low as needed.

The general idea is that power pins are listed by name, rather than being connected to symbols with pin numbers. I'm not exactly sure what's the best way to represent/store that info, but I know it doesn't belong in the *gate*. My idea is to have a table object that shows up in the schematic, like in a corner or something, that lists all the power pins and what nets they connect to. I've seen other schematics with this, it seemed much cleaner than what we do.

How we populate the table, who is responsible for it, how the user edits it - if it's even in the schematic at all - is TBD. Heck, you don't even know what the power pins *are* until you've selected a package, and that's way down the line flow-wise.

As an aside, support for a table of pin mappings opens itself up to FPGA mappings, too - just supply a CSV instead of trying to map it to a schematic.

Back Annotation

This is another thorny issue. I think the moment we allow gate swapping, we need to put a unique identifier on each symbol, beyond the refdes. Why? Because we're going to be changing the refdes if we swap gates between chips, and even just simple gate swapping means you're dealing with two symbols named U4 - how do you know which symbol is which? You want that symbol, not "some symbol named U4".

However, once that's figured out, pin and gate swapping uses the same back-annotation mechanism as package assignment. Some mechanism tells gschem (or libgeda) to assign pin number NN to pin ABC on part U4a (or part UUID#7189512). With inter-chip gate swapping, it also tells gschem the new refdes.

Perhaps pcb could generate some scheme script that gschem runs. Alternately, DBUS, as we may end up using that to implement the pin mapper anyway.

Another idea is to have PCB be the "keeper of the pin assignments". Each time it runs gnetlist, it exports the current pin mapping. Gnetlist uses the current mapping as a starting point, and allocates pins from the pin mapping in the database (or provided by pcb) based on what pins are available