Is this a dead horse? Adding Components and Packages to KiCad's Symbols and Footprints

Projects
1

This Request for Enhancement has seemingly been popping up forever, as an impediment to newcomers and a PITA for the experienced - yet it never seems to get past the “it works for me the way it is, why would anyone want things to be different?” stage:

  • kicad doesn’t support the concept of symbols that are associated with a set of footprints.

Today, in a schematic, the designer focuses on Symbols, while the layout designer lives and dies by Footprints. Both are constrained by reality - products rarely make it to market when they depend on unobtanium components or imaginary packages. There is a missing third person in the kicad universe - the library maintainer / component designer who decodes those pesky data sheets that tell us exactly which footprints to use for a particular component that incorporates the symbol(s) used in the schematic.

That’s the workflow disconnect. Going from Symbol to Footprint is a multi-step journey: Is my “R” a singleton or part of a SIP/DIP? What Footprints are valid for this IC Symbol? CAD programs should work to make it easy to produce high quality results by taking care of the “fiddly bits”.

IMO, KiCad needs to articulate the concept that “A Symbol is associated with a set of Footprints”. There are only a few footprints that are appropriate for a specific symbol - think ICs where the data sheet specifies the footprints being produced, DIP, SIP, SOP, SSOP, TSOP, MSOP, QSOP, SOIC, QFP, TQFP, BGA, etc, in reflow, wave and hand solder variations. Resistors come in 1w, 1/4w & 1/8w PTH, as well as 0805, 0603 (…) SMT footprints, but not in SOT or QFP…

If there is an appetite to address this, consider leveraging the real world concepts of “package” and “component”: Components map [a set of equivalent Symbols] to [a set of Packages], while Packages map a Component’s Symbol’s Pins to the Pads in a specific Footprint, something that is hard coded today in KiCad.

The motivation is threefold:

  1. KiCad projects are higher quality: The kicad library creator can produce validated components that associate a Symbol with all the Footprints that it comes in - addressing the problem of “what is actually available?”
  2. KiCad users are more productive: The various project designers (Electrical engineer, Layout expert, inventory manager…) can confidently manipulate their part of the project, starting with the EE’s “need to make it work”, moving on to the Layout engineers “need to make it fit” and finishing up with the operation beancounter’s “need to use the lowest cost item in inventory”. With the addition of the component and package concepts, each of these three dimensions can safely operate alongside the others, and be confident that the result won’t end up being yet another coffee coaster.
  3. KiCad maintainers have more work to do :slight_smile: : Duplication and bloat in KiCad’s existing libraries could be reduced (US-vs- EU Symbols, footprint variations…)

I’m not sure KiCad can make a change as pervasive as this, given the inertia of the installed user base…

3 Likes
2

I think the basic problem is Kicad Libraries do not have an annual multi-million dollar budget.

Symbols, footprints and 3D images are thrown out there in libraries suitable for people to use, modify and re-categorise as they wish through the provision of, easy to create, personal libraries and data bases.

1 Like
3

A few days ago I installed the AKL (Alternate KiCad Library from the Plugin and Content manager) It doubles the size of the installed libraries. It’s got hundreds of diode bridges and lots of other things. It is a quite impressive library (have not verified accuracy) But it also shows the limits of KiCad’s library system. It’s only two levels deep. One level for libraries, and the 2nd for the parts (symbols / footprints (or combinations)). AKL also has resistor networks (with multiple units).

I guess that at some time in the future KiCad’s library system will be refactored, but as JMK already posted. it available resources are limited, and that defines KiCad’s development pace.

There are also complications that the same symbol, but in different packages can have a different pinout. So this would need either an extra level of indirection, or just keep it as it is now with two symbols, one for each footprint with it’s own pinout (ATMEGA328 is an example of this).

I have not used the database driven libraries myself, and I don’t know how flexible this system is. Maybe at some future time the default libraries (or an alternative form of the default libraries) will get put into such a database. But I don’t know much about this part. I am not even sure if this would make sense.

1 Like
4

Is this really a thing? When I select my components I check for availability and assign the proper footprint. Since (I believe) most people working with KiCAD are either single persons or small teams so the schematic and layout are done by the same person. Even when doing design with >1000 components I never felt the urge to assign a set of footprints because why? If a footprint does not fit you go back to the schematic and change it. Besides that you can add a footprint filter to your symbol where you can assign multiple footprints. Or maybe I’m not really understanding your proposal so maybe you could enlighten me further ^^

1 Like
5

I see the benefits of a tighter bond between symbol and footprint.
To pull something in the complexity of Altium, I doubt there is enough capacity available.
Also those Libs do have their caveats, too.

The current approach in KiCad, where you can filter by Pins and Prefix is pretty clever.
Did you even try that? @JohnP

When I e.g. try to look for a new footprint for a Resistor and check the two boxes, I get a pretty narrowed down selection of Footprints:

grafik
grafik429×615 9.05 KB

6

KiCad does already support this concept though.

As noted, right now the only requirement is that the pins all have matching names with the pads.

7

Note also that the Footprint Filter doesn’t have to be a prefix. It could just be a list of 3 footprints that can be used for that symbol.

(And, FWIW, in 9.0 there is a DRC check that the footprint chosen matches the symbols footprint filters. Though you have to turn it on manually; its severity defaults to “ignore”.)

1 Like
8

To keep with the ATMEGA328.

KiCad has 10! different schematic symbols for it:

image
image1089×793 152 KB

And there are at least 3 different pinouts, depending on the footprint (DIP, TQFP, QFN). (Sidenote: does it make sense to have more then 3 (one for each of the pinouts) in KiCad at all?)

image
image836×619 21.1 KB

The QFN also has two extra pins. Some probably also have a thermal pad on the bottom that KiCad has hidden (sigh).

At the moment these are all different schematic symbols. How useful would it be to change the library system in such a way that these get merged in some kind of way? At the moment I am quite happy with direct pin to pad translation. When it’s needed, I guess I’d rather copy and modify a symbol then to fiddle with an extra pin mapping table somewhere. It’s simple and straight forward and does not happen all that often.

The “aliases” work for symbols which are the same, but can be mapped to many different actual parts. Opamps are a good example for this. The current method feels like a bit of a kludge, but “it works” reasonably well anyway.

And overall, storage is cheap. Improvement should be more implemented in the way of easier maintenance, and symbol creation. Most symbols are rectangular boxes with pins. I have once seen a side project for:

  1. Copy pin data from datasheets.
  2. Pasting it in a spreadsheet.
  3. Add some meta data (Pins left, right, top, bottom, gaps between pins, etc)
  4. Run a script and the symbol is ready.

It may be useful to integrate something like this in Symbol Editor / Edit / Pin Table. gosh, I just clicked on the + in the pin table, and it auto increments the Y position with 100mils. That’s a nice touch. Draggin pins in the GUI is also easy to visually align with gaps etc. But entering data for a 1200 pin FPGA?

But I guess that symbol design is a bit off topic in this thread, and there already are gitlab issues for that too.

9

I’ve been designing electronic products for many years. Looking back I don’t see how this would be any benefit at all.

As an electronic designer I choose a part, at the same time I choose the package, package material, the need for any cooling (whether thermal pads of physical heat sinks). When I’m done I had these and other design requirement to the PCB designer. Even if I am the PCB designer the same process applies.

If there were such a connection as you described, would call those footprints “standard” for a certain company for example.

If I (electrical) pick a package that isn’t “standard” then its up to me to justify the package I choose. Then the (PCB) person will use that package regardless of what is linked to that resistor, transistor etc.

Before easily attainable PCB programs were available we would use outside PCB design services. We would give them information for every part. Without exception, they would make a footprint for every part we specified. I asked why don’t they use “standard” footprints. The answer is: the footprints are so easy to make that the risk of a standard footprint not meeting our specifications was too high.

Add to all this the fact that component physical designs are changing so often one cannot easily keep up with these changes with such a database (aka link to standard footprints).

2 Likes
10

Neigh.

Organisation of the database can take many forms. The beauty of the KiCad database connection technology is that you can configure the backend to suit yourself. If you have the disk space for the database, nothing is stopping you from storing a symbol with all the variant footprings.

The next advance I think is when the schematic editor gets a stable extension language API which can also interact via the GUI, and several key points in the code, like choosing a symbol can be redirected to plugin code. Then people who want more elaborate symbol selection UIs can roll their own.

1 Like
11

We are somewhat doing that using the KiCad Database feature – see this example:

In this case, ANA-0002 had two different variants, and two different packages. It turns on in this example, the symbol is different, but we could have cases where the same symbol is used with multiple footprints. Each one will have a different IPN, as they are different parts.

In every design I’ve worked on, the design engineer specifies the package, as there are thermal and other concerns. If there is an issue at layout or procurement, then the engineer collaborates with these people to change the part.

In the end, I want a different IPN for every part used, and I want these in a reusable database.

The database or HTTP connection really gives you a lot of flexibility to do whatever you want.

1 Like
12

@Cliff_Brake - Thank you thank you thank you!

Git-plm looks to be everything I’ve been wanting in kicad library structure since forever!

I’m going to jump down that rabbit hole and see if I can integrate my own parts/footprints/packages library into it…

-John

13

Let me know how it goes. The current gitplm app is a little out of date (note, the app repo is different than the parts repo) as it has not been updated to use the new KiCad database CSV format, where each category is in a separate CSV file, but with the KiCad database stuff, there is less need for the gitplm app. So at this point, the gitplm app is only really needed to put together BOMs for multi-level projects, and run release scripts. We’ve done some neat stuff lately with kicad-cli to completely automate the release process for PCB in KiCad.

Hopefully, I can get this all updated soon, but the parts repo should be very usable now – we’re using it on several different projects.

14

4 posts were split to a new topic: Importing parts is a pain

Deviation from the original topic about organising libraries which deserves a new topic.

16

Using a different Symbol for every footprint variation is balky, clumsy, st…
Other programs have solved this in a better way using a “Device”, or “Component” hierarchy level, with one Symbol, and as many footprints as you like, reflecting the reality that silicon dies can have many different packages.

This is a higher priority than 3D rendering, that bloats libs, and have little usefulness, unless very cramped injection-molded package integrations are used, which is unlikely in the KiCAD space.

A “Device” should have one “Symbol”, then different Footprints are connected in a separate screen according to the datasheet.
This makes it easier to switch to another package without ripping up schematic.
Unused pins can of course be left unconnected.
Ground and thermal vias can be conveniently included in center pads.

I don’t think I ever used a stock library symbol or footprint. Stock symbols are usually too large, not descriptive, not reflecting physical chip layout that is needed for RF.
There is no standard for every package that you can trust. Small variations for RF parts can be detrimental. Data sheets have to be studied for every part.
Footprints also need to consider SMT processes and stencil cleaning, for which corners needs to be given a radius. No reason to ever have sharp corners on pads. Take a look at a stencil pasted board.

Time for improvement.

1 Like
17

Please point me to the authoritative user survey you apparently have done, or to some other reliable source which proves this isn’t just your opinion. Meanwhile I reserve the right to put you in the same locker with many others who claim they know how an EDA program should have been made.

18

I would not do anything for some dude on the net with a smug attitude, and that seems to be convinced his baby is the greatest
YOU show me the authoritative survey that KiCad blows the doors off every EDA package on the market.
KiCAD has changed a lot over the years, because it was originally perfect?
Get a grip.
Altium is so worried now.

19

Please stay a bit polite towards each other here
(Gosh, I’d ever thought that I would write that here :slight_smile: )

I had a short look at **/usr/share/kicad/symbols/MCU_Microchip_ATmega.kicad_sym for the ATmega328, same example as the screenshots before, and it’s definition is quite short. It starts with:

	(symbol "ATmega328-MM"
		(extends "ATmega48PV-10MM")
		(property "Reference" "U"
			(at -12.7 36.83 0)
			(effects
				(font
					(size 1.27 1.27)
				)
				(justify left bottom)
			)
		)
		(property "Value" "ATmega328-MM"
			(at 2.54 -36.83 0)
			(effects
				(font
					(size 1.27 1.27)
				)
				(justify left top)
			)
		)

And the whole definition is just 7 of those “properties”.

Also, as an Open Source project, KiCad grows in little increments. Where KiCad came from long ago, it’s library system was perfectly adequate, and now 30 years later, it’s seams are getting tight. I like the idea of the database driven libraries, and those can also work perfectly together wit partial blocks of data such as loose footprints. I mostly see the hobby and forum sides of KiCad and have not used these database driven libraries at all. But from the little I know this should work quite nicely with integration for already implemented databases that companies have built up during the their time “before KiCad”. And I think it’s a good division. Hobbyists have a nice assortment of simple parts they can easily modify and make to fit into their projects, and companies can re-use their in-house databases that have been built up over many years.

A few weeks ago I installed the AKL (Alternate KiCad Library) and it doubles the amount of available symbols in KiCad.

The file:

~/.local/share/kicad/8.0/3rdparty/symbols/com_github_dawidcislo_alternate-kicad-library/Diode_Bridge_AKL.kicad_sym

is 921KiB and it has 879 different diode bridges in it. That is >>> 921*1024/879 = 1072 characters per symbol, which seems pretty compact, considering KiCad’s “verbose” use of S-Expressions. (For the curious, it’s just 21KiB when zipped. 16KiB with .7z.) And there is a lot of graphics re-use. I guess there are just 8 different graphic symbols, one for each pin combination.

And overall, I also do not care much what the size of those libraries is. The time and effort for maintenance is much more important, and graphics reuse helps a lot here too.

I also very much appreciate the ease of use of the “simple” / generic symbols for resistors and capacitors. You just grab some resistors and capacitors to quickly put down an idea on a schematic, type in some values, If you have models for the IC’s you can make some simulations, and when you want to go though with a PCB, you can add footprint data later. I see this as one of the core strengths of KiCad.

I am trying but I’m having difficulty in understanding what the actual problem is that supposed to be addressed in this thread. Going back to the original post:

But KiCad does support this via the keywords in the footprints. If you use the Footprint Assignment Tool, and filter for the Keywords, then you get only resistor footprints when assinging a footprint to a resistor.

OP complains there is bot a US and an EU resistor symbol in KiCad’s libraries, but he also wants reflow, wave and hand solder variants for footprints. (Those can also be easily swapped with Schematic Editor / Tools / Update Symbol Library Links

@JohnP Have you ever used the Footprint Assignment Tool and filtered for Keywords? Is this close to what you want?

So I’m still not sure what the actual problem is. I suspect that you mostly used one way of combining symbols with footprints, and are unaware of the other options that are also supported by KiCad. It is possible (plausible) that these footprint filters do not work good enough in some cases, but that is probably due to some errors or omissions in KiCad’s libraries. Nothing except Leeloo is perfect on this mudball.

20

I have a large library constructed over the last 30 or so years of use with several different CAD/layout programs. As many here have said, in one form or another, “I don’t trust a symbol / footprint that I haven’t personally validated” - because I’ve been burnt too many times.

@JohnP (me) wrote:
kicad doesn’t support the concept of symbols that are associated with a set of footprints.

@paulvdh writes
But KiCad does support this via the keywords in the footprints.

@craftyjon writes:
As noted, right now the only requirement is that the pins all have matching names with the pads.

I understand the “use a resistor footprint filter for the R symbol”, or even “provide a list of specifics…”. Cumbersome, but workable, I guess. Until someone adds a footprint that matches an existing filter or worse, doesn’t, or the filters pick out unobtanium combinations or ones with pin quantity/name mismatches. BTW, dandruff components are easy and not worth the trouble… the complex ones are the ones that matter to me.

@JohnRob wrote:
We would give them information for every part. Without exception, they would make a footprint for every part we specified

And what happens when you mistakenly give them the wrong information - say misreading a datasheet and specifying a TSSOP package that isn’t actually manufactured for that device? Yeah, making footprints is easy, that’s not the point: I want to make it easy to use correct, in-production footprints that are known to work!

As an example, I’ll use the ATmega called out earlier in this thread. KiCad has what? Three or more slightly different symbols, filters for two or three footprints and a bunch of trial and error sleuthing just to address a subset of the Atmel ATmegaAVR product offerings.

What I want (and looks to be potentially do-able with some scripting and sql using git-plm) is to create VALIDATED PACKAGES.

Each PACKAGE would associate a SYMBOL with a set of FOOTPRINTS, the PIN MAPPINGS that match the data sheet(s) from a vendor and a list of all the available component VALUEs. Why? So that, when I use this product in my design, I don’t have to guess about footprints, manufacturing part numbers and ordering info - the reasons I built my own personal library in the first place.

The workflow I want is

  1. Create my validated Library of PACKAGES
  2. Add a Package’s SYMBOL from that Library to the schematic.
    • ATmega megaAVR
  3. Choose a Package VALUE for the device.
    • ATmega328P
  4. Choose a Package FOOTPRINT - possibly deferred until I get to the PCB stage…
    • 28P3 - 28-lead SPDIP

See the resulting Part Number in the PartsList, BOM… ATmega328P-PN

Peace,
John

Example:
PRODUCT:

ATmega megaAVR

Acceptable VALUES for each of the available devices:

Not possible AFAICT today in KiCad

The ATmega48A/PA/88A/PA/168A/PA/328/P differ only in memory sizes, boot loader support, and interrupt vector sizes. The table below summarizes the different memory and interrupt vector sizes for the devices.

Table Memory Size Summary

Device Flash EEPROM RAM Interrupt Vector Size
ATmega48A 4KBytes 256Bytes 512Bytes 1 instruction word/vector
ATmega48PA 4KBytes 256Bytes 512Bytes 1 instruction word/vector
ATmega88A 8KBytes 512Bytes 1KBytes 1 instruction word/vector
ATmega88PA 8KBytes 512Bytes 1KBytes 1 instruction word/vector
ATmega168A 16KBytes 512Bytes 1KBytes 2 instruction words/vector
ATmega168PA 16KBytes 512Bytes 1KBytes 2 instruction words/vector
ATmega328 32KBytes 1KBytes 2KBytes 2 instruction words/vector
ATmega328P 32KBytes 1KBytes 2KBytes 2 instruction words/vector

SYMBOL

a SYMBOL definition for an Atmel ATmega

PACKAGES for the 4 footprints the device is available in:

32A - 32-lead, (1.0 mm) Plastic Thin Quad Flat Package (TQFP)
28M1 - 28-pad, 4 x 4 x 1.0 body, Lead Pitch 0.45 mm Very Thin Plastic Quad Flat No-Lead (VQFN)
32M1-A - 32-pad, 5 x 5 x 1.0 body, Lead Pitch 0.50 mm Thin Plastic Quad Flat No-Lead (VQFN)
28P3 - 28-lead, 0.300” Wide, Skinny Plastic Dual Inline Package (SPDIP)

PIN-MAPPINGS for the above

not possible today in KiCad with a single SYMBOL…

Footprint 32A:

ATmega48A-AU
ATmega48A-AUR
ATmega48PA-AU
ATmega48PA-AUR
ATmega48PA-AN
ATmega48PA-ANR

ATmega88A-AU
ATmega88A-AUR
ATmega88PA-AU
ATmega88PA-AUR
ATmega88PA-AN
ATmega88PA-ANR

ATmega168A-AU
ATmega168A-AUR
ATmega168PA-AU
ATmega168PA-AUR
ATmega168PA-AN
ATmega168PA-ANR

ATmega328A-AU
ATmega328A-AUR
ATmega328PA-AU
ATmega328PA-AUR
ATmega328PA-AN
ATmega328PA-ANR

Footprint 28M1:

ATmega48A-MMH
ATmega48A-MMHR
ATmega48PA-MMH
ATmega48PA-MMHR
ATmega48PA-MMN
ATmega48PA-MMNR

ATmega88A-MMH
ATmega88A-MMHR
ATmega88PA-MMH
ATmega88PA-MMHR
ATmega88PA-MMN
ATmega88PA-MMNR

ATmega168A-MMH
ATmega168A-MMHR
ATmega168PA-MMH
ATmega168PA-MMHR
ATmega168PA-MMN
ATmega168PA-MMNR

ATmega328A-MMH
ATmega328A-MMHR
ATmega328PA-MMH
ATmega328PA-MMHR
ATmega328PA-MMN
ATmega328PA-MMNR

Footprint 32M1-A:

ATmega48A-MU
ATmega48A-MUR
ATmega48PA-MU
ATmega48PA-MUR
ATmega48A-MN
ATmega48A-MNR
…

Footprint 28P3:

ATmega48A-PU
ATmega48PA-PU
ATmega48PA-PN
…

1 Like
21

My company uses database libraries. We started several years ago with Altium, and it made library management an order of magnitude easier. We now have a small symbol library and a large footprint library. Making new parts that use existing symbols and (tested) footprints is a breeze. It has reduced our error rate due to bad footprints and BOM errors to almost zero.

When we started moving to KiCad, we added a couple fields to point to the KiCad symbol and footprint folders (since we duplicated everything for KiCad), and it worked, i.e. we have one single database library for both programs.

If I ever do this on my own, as a hobby or otherwise, I will go straight to a database library.

Just my 0.02 in local currency.

John

2 Likes