kicad-developers team mailing list archive
Mailing list archive
Re: Atomic Libraries Proposal
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
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")
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.