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=14In this example, items in parentheses are swappable and items in square brackets are groups. The corresponding symbol would have pins labelled A, B, and Y, which would map to one of four mappings (group [ABY] maps to swappable groups (,) etc) which in this case correspond to the four gates in the chip. For each gate, note that the two input pins (A,B) are swappable - either pin could be mapped to either pin number. Another example for a RAM chip:
(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 = 16Note that the grouping may be implied, but it's (hopefully) obvious from the example that any of the four data pins are interchangeable, as are any of the eight address pins. However, you must be explicit about grouping when it's not a one-to-one mapping, such as the transistor problem. Consider a MOSFET - it can come in a SOT-23 package or 8-SOIC. Here's the SOT-23 case:
G = 1 S = 2 D = 3Here's the 8-SOIC case, showing how to map a single schematic pin to multiple footprint pins:
G = 4 S = [1,2,3] D = [5,6,7,8]A fictitious example of two transistors in one package:
[G,S,D] = ([1,[2,3],[10,11,12]], [7,[8,9],[4,5,6]])Note that we have to switch to a single-line entry to group the "transistors" together for swappability, but each pin within each transistor maps to either a single pin or a group of pins.
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 :-)
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.
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.
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
|webmaster donations bookstore||delorie software privacy|
|Copyright © 2013 by DJ Delorie||Updated Jul 2013|