← Back to team overview

kicad-developers team 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
 - symbol+footprint+3d
 - 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 library" filter.

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

    symbol: generic:diode
    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 same thing.

  - 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.