kicad-developers team mailing list archive

[Simon Richter <Simon.Richter@xxxxxxxxxx>]

Hi,

On Thu, May 23, 2019 at 03:41:20PM -0400, Seth Hillbrand wrote:

> After some discussion, we are trying to decide whether implementing
> a basic atomic library support would be useful during v6 or would
> cause more headache than worth while trying to work with the
> solution.

I have a counter-proposal, but not yet written in document form, aiming to
integrate atomic libraries with the existing ones.

The basic idea is that symbol definitions form an inheritance tree:

 - symbol type (e.g. "diode", "resistor", ...)
   - component specification (e.g. "1N4001")
     - package (e.g. "0603")
       - vendor
         - supplier

Each layer adds more information about the part, and possible actions in
the UI depend on the level of detail currently selected.

E.g. if I have placed a generic diode, I can neither convert to PCB nor
simulate, but the symbol is there already. If I select the particular
diode, but not a package yet, simulation becomes possible because the SPICE
model is attached to that layer. If I have a package selected, I can design
a PCB, and a "change package" action in the PCB can present me with
different package options as well.

There are quite a lot of details to be worked out still, random thoughts:

 - US vs EU vs GOST symbols, can we somehow make them use the same pin
   positions and different graphics, so these become interchangeable?
 - 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)?
 - on which layer should pin to pad mapping happen? Can we fold our six
   transistor symbols (BCE, BEC, CBE, CEB, EBC, ECB) into one and allow
   switching mappings during PCB design?
 - can we hardcode that hierarchy, or should the library be free to diverge
   from that (i.e. generic inheritable properties)?
 - are there any symbols that would not fit that mold?
 - can we add additional fields sensibly (e.g. generic "resistor" would
   define that there is a field "power rating", and the package or vendor
   layer would provide a value)? Can we filter on these?
 - while we're at it, can we drop the requirement that ICs have a graphical
   symbol, and just treat the pin table like a hierarchical sheet?

Such a hierarchical system would IMO be the best of both worlds: atomic
libraries would benefit from being able to reuse graphics with a single
click, and it would still be easy to throw together a quick schematic from
generic components and successively refine without having to decide on
packages and suppliers right away.

Last but not least: a way to version individual symbols and allow users
access to multiple versions might also be very useful here.

   Simon