kicad-developers team mailing list archive

[Simon Richter <Simon.Richter@xxxxxxxxxx>]

Hi,

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

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)
                    45678
                    other footprint -> bjt_sot_23_bce -> (fp only)
                                                         34567

so again, the difference between workflows is merely a filter, and both use
the same library.

   Simon