Chip footprints with varying IPC density

[evanshultz]

IPC 7351B land patter naming shows three suffix letters to be placed at the end of the footprint name (except for BGAs) to indicate the density. They are:

• M: Most Material Condition (Level A)
• N: Nominal Material Condition (Level B)
• L: Least Material Condition (Level C)

We currently have built all footprints to Level B. I would like to introduce Level C for chips because it's quite useful to get vias closer to the pads, especially in high-dV/dt situations.

This issue is to try and figure out what the footprint names should be so the generator can be updated to suit the decisions here.

My first thought is to keep the existing footprint names and add _L to the end. It may conform best to IPC is the existing footprints end in _N, but IMO that's unnecessary as the nominal density can be considered the default condition and users would normally select it and consider the one with a suffix as some variation. Users who knew about IPC density levels and wanted more dense footprint are probably capable, especially with the improved descriptions we would need for our footprints, to find these footprints and use them.

Thoughts? I wouldn't be surprised if there's a better scheme but keeping some relationship to IPC's recommendation when building footprints to their standard seems prudent to me.

The doc mentioned above is widely available online, for example at http://ohm.bu.edu/~pbohn/__Engineering_Reference/pcb_layout/pcbmatrix/IPC-7x51%20&%20PCBM%20Land%20Pattern%20Naming%20Convention.pdf.

[poeschlr]

Do you plan on including these different density level footprints in the official lib? Because if yes then you might want to ask this over on the footprint repo.

The generators already come with a --density option that allows overwriting the chosen density for all generated footprints so users can generate them quite easily. I could add a suffix to them but would make it probably longer than what you suggest (Something like _Density<M|N|L> could be an option, this suffix should then not be used for the 3d model as it will be reusable. This would fit the general syntax we normally use. Alternatively with a dash: _Density-<M|N|L>)

[evanshultz]

Yes, my thought was to introduce them into the official lib using some suffix as noted above. I know I can generate them easily but I wanted to ask about the footprint name first because that would affect the footprint name.

This repo seemed reasonable to me because you may be the person to know and care most about naming. I can ask over at the footprint repo, but what is the objective? The same questions I asked about or is there a specific audience you want to reach with a specific question?

[poeschlr]

The reason to have discussions about that on the correct repo is such that users can (at least in theory) add their voice. Kicad is community driven and it just kind of feels wrong to have a discussion in some hidden place (this repo is not really part of kicad at this point in time.)

I assume you are aware that adding different densities would triple the library size (If we add more then one then we might as well add all 3). This would mean dfn/qfn is then suddenly 1200 files. (ok a bit less as not all of them are scripted -> i hope to change that sometime in the future.)

For v6 we will then definitely need to split it. (At least along dfn and qfn, possible even more.)

[evanshultz]

Sure thing. I've posted https://github.com/KiCad/kicad-footprints/issues/1836.

[poeschlr]

My next bigger project will be an improved footprint naming manager. The format string stuff is simply a mess that needs fixing. As well as a proper IPC settings handler so the scripts will get this possibility in some not too distant future.

[evanshultz]

Sounds great!

I would like to see https://github.com/pointhi/kicad-footprint-generator/pull/438 merged to build C, L, and R footprints with unique body sizes, and then I'm happy to take a crack at this.