kicad-developers team mailing list archive
Mailing list archive
Re: Atomic Libraries Proposal
Am 24/05/2019 um 13:32 schrieb Wayne Stambaugh:
Just as an FYI in case it wasn't obvious, Seth's proposal uses library
IDs to define the symbol and footprint.
Yes, so would mine, on any level that is more detailed than "footprint".
The main problem I see with atomic libraries is that "fully defined" is
not fully defined. Is it
- symbol+footprint+order no
- symbol+footprint+3d+order no
or any of these, and a SPICE model attached?
That's why my proposal is to define a hierarchy based on a "non-atomic"
workflow, starting with generic components and refining until you have
an order number attached to the part as well, because that is still
useful even if you prefer to define everything at once: you just use the
"fully defined" parts then and filter out the generic and partially
defined ones during selection.
Workflow for part creation would be
1. define the symbol:
- draw one, *or*
- select an existing one, *or*
- go with "generic box with pin definitions"
During this step, pin numbers are optional, but you can already enter
them if you want.
2. attach a SPICE model, or skip this step
3. define the package
- draw one, *or*
- select an existing one
The pin mappings from step one are then transferred to this layer.
4. optionally, attach a 3D model
5. optionally, attach a manufacturer part number
6. optionally, attach a distributor part number
Each of these steps generates a new symbol internally, and if you are in
"atomic library" mode, hides the previous one in the selection dialog.
This becomes useful already when you define your second diode: even if
you defined a 0603 1N4001 part complete with DK order number first, you
have a standalone diode symbol now that you can reuse, and if you do,
swapping out parts in the schematic becomes easier:
- we can add a "exchange part with ->" context menu with other diodes
that use the same symbol
- any other diode will be properly connected without adjusting any
wires, because the pins are in the same place, and anode and cathode
have the same pin names.
If you don't like atomic libraries, or you're just doing a quick drawing
that should never go into production, you can use "incomplete"
definitions in the schematic as well, by deactivating the "atomic
The idea is to make the "atomic libraries [y/n]" decision a pure UI
thing, so a single library can work for either workflow, and both camps
can contribute to the shipped kicad library.
This means that in order for
the atomic libraries as proposed to be portable, the symbol, footprint,
and 3D model would have to be available on the host machine. Otherwise,
any missing symbol, footprint, and/or 3D model would break the library.
The hierarchical model could degrade somewhat gracefully here, by
storing references to all layers: the schematic would say
value_symbol: diode:1N4001 (inherits generic:diode, adds SPICE)
footprint: diode:1N4001_0603 (inherits diode:1N4001, adds FP/3D)
mfgno: 12345 (inherits diode:1N4001_0603, adds part number)
orderno: 67890 (inherits 12345, adds order number)
each of these fields would be a library reference, and import would just
initially go with the most specific one it can find locally:
1. does the local library have a symbol "67890"?
2. does the local library have a symbol "12345"?
3. does the local library have a symbol "diode:1N4001_0603"?
etc., so if you are missing the manufacturer and distributor levels, you
at least get the symbol, SPICE, footprint and 3D model, and if you
derived your own manufacturer and distributor levels from the generic
ones, a "refine part selection" context menu could immediately provide
them for you.
- US vs EU vs GOST symbols, can we somehow make them use the same pin
positions and different graphics, so these become interchangeable?
This technically isn't atomic but could be supported with the new file
True, that's why I put them under "random thoughts". It'd be nice if we
could somehow teach KiCad that different graphical symbols can mean the
- multi-unit components, can we somehow make them inherit the generic
symbol multiple times and thus allow unit mapping without changing the
schematic (i.e. gate swapping)?
I'm not sure what you mean here. Doesn't changing a symbol gate change
the schematic? The symbol will have to be a complete symbol not just
one of the sub-units. I don't see how it's possible to associate a
footprint to a single gate of component.
Sorry, that was unclear, it should have been "without having to adjust
wires in the schematic".
Swapping a part with one that uses the exact same graphical symbol can
be done without risking connectivity, so it becomes possible to quickly
exchange unit A for unit B, or switch from a two-unit to a four-unit
package, and we could even offer that from within pcbnew because we can
guarantee that we can adjust the schematic without breaking it.
This becomes really interesting if we want to switch a CBE transistor
with a BCE one during layout: they use the same pin names in the generic
symbol, so exchanging them in the schematic is safe, and the pin mapping
is in the footprint definition (that even in an "atomic" workflow the fully
defined part inherits from).
I.e. my library has
- graphics: generic:bjt
- footprint: bjt_sot_23_cbe
- mfg: 23456
- mfg: 45678
- footprint: bjt_sot_23_bce
- mfg: 34567
my schematic contains a 23456 part, and during layout I find that a
34567 part would fit better. Since they both share the same symbol on
the "graphics" layer, we can exchange them easily, but we need to
recompute the netlist. If we exchange the part with a 45678, the netlist
is unchanged because they share the same footprint definition.
If the UI is set up for "atomic" workflow, the context menu would offer
- exchange with -> 45678
other footprint -> 34567
In a non-atomic workflow, the menu would look like
- exchange with -> bjt_sot_23_cbe (fp only)
other footprint -> bjt_sot_23_bce -> (fp only)
so again, the difference between workflows is merely a filter, and both use
the same library.