The version 6 wishlist

[poeschlr]

This issue is here for every user and maintainer to add their wishes of how the library should change for the v6 release. There is no guarantee everything will be implemented but lets collect ideas here.

---

I suggest as deadline end of may until we make a decision which of the suggestions to target and with what priority. The first post will in the end be edited with the final rating

[poeschlr]

My first ideas:
symbols

• Get rid of invisible power input pins for all symbols except power symbols (such symbols should not create global labels)
• If the new file format has a better alternative to hidden power input pins for power symbols then use that instead
• Rework the switch and relay libs to use standardized pin "numbers" (11,12,14; 21,22,24; A1,A2...) as this would allow the use of generic symbols
• Use the new naming convention for the switch and relay libs
• If the new symbol file format allows for "aliases" to have their own footprint field then maybe use more "aliases" than now
  • We could even go so far as to have an "alias" representing our connectors (would make it easier for users to find them when placing the symbols)
• If there is an alternative to stacking pins then use that

footprints

• Split DFN/QFN (generic libs plus maybe manufacturer spezific if the latter is still required, otherwise get rid of all the manufacturer specific footprints)
• Split SO lib (i have no clear plan yet how we would split it)
• Split the capacitor lib
• If there is a better alternative than directly linking the 3d model file then use that feature
• Make use of the new pad shape (chamfered pad)

[calebreister]

I have a few ideas, though some of them may be beyond the KiCad library scope.

Symbols

• Fix alignment issues with analog switches, provide additional aliases.
• Add an alternate function mechanism to allow pin names to changed for symbols such as microcontrollers. For instance, a user could select an alternate function by right clicking on a pin and selecting it. This could also improve rule checks.
• Test and fix broken datasheet links
• Overhaul 74x lib(s)

Footprints

• Better connector organization (Samtec could really use some re-organization)
• Improve PCB edge footprints
  • Edge.Cuts layer in footprint files?
  • Create edge variants of connectors that are commonly placed at/near the edge of a board (such as barrel jacks)
• Footprint aliasing to support multiple 3D models (such as connectors with different heights)
• Create an official repo for footprint script + YAML (or JSON) files
  • Add Python and YAML/JSON conventions to the KLC (or another set of contribution guidelines)
  • One footprint per YAML entry!
  • Provide a way to easily identify script-generated footprints and track them back to associated source files

3D Footprints

• Better/more detailed contribution guidelines
  • There should be a strict policy on the use of manufacturer-provided models and to what extent contributors are allowed to reference such models.
• Establish some kind of convention for script-generated models
  • Specify the allowed scripting languages. A few candidates are:
    • FreeCAD scripted objects
    • OpenSCAD
    • libfive
  • Settle on a file format for 3D metadata (similar to the YAML/JSON format for script-generated footprints)

[poeschlr]

There should be a strict policy on the use of manufacturer-provided models and to what extent contributors are allowed to reference such models.

There already is a strict guideline about that. https://kicad-pcb.org/libraries/klc/M1.1/ I mean the word "should" is really a "must" but well that is a general problem of the klc. (we were too polite when we wrote it)

[chschlue]

Symbols

General:
Not sure what to do with the new format yet, especially reagarding derived symbols. Requires further testing (and playing around).
Special:
I'd like to put Comparator, Amplifier_Operational and Interface_UART libs on my personal to-do list.

Footprints

RFC:
Try and reduce FP duplication. This especially pertains to QFN and SO libs @poeschlr already mentioned. Derived footprints/footprint aliases would come in handy here.
This flares up in PR comments every now and then but with a real solution AFAIK.
Let me explain: Currently, we generally follow datasheets for footprint naming to avoid user confusion. This leads to duplicates like SOIC-8_3.9x4.9mm_P1.27mm and SO-8_3.9x4.9mm_P1.27mm, for example, which are actually the same MS-012 package. This could be avoided by having something like a JEDEC_MS-012-8_3.9x4.9mm_P1.27mm footprint with alias names SOIC-8... and SO-8....
Then we have Package_DFN_QFN (DFN should be sliced off like @poeschlr said) and Package_CSP, which are actually either MO-220 QFNs or BGAs. Whether they're chip-scale or tiny-die-in-a-friggin-huge-package is completely irrelevant footprint-wise.
QFNs also suffer from inconsistent naming among manufacturers (NXPs VQFN is Microchip's TQFN and the like). This would also be solved by having a MO-220-<insert variant here FP with aliases.
Next, many QFNs only differ in EP size (which isn't standardized). Solution: Derived footprint only changing a single pin.

Note 1: Aliases might require manufacturer prefixes to avoid collisions. We already had at least one naming collision in the current libs but I can't seem to find the PR right now.
Note 2: Note 1 partly contradicts the proposal to get rid of manufacturer-specific footprints (but as aliases instead of full-fledged FPs
Note 3: This doesn't have to be finished by v6's release, only the foundation would have to be there.
Note 4: In case this proposal isn't summarily rejected, it should get its own issue because quite a lot of discussion and testing would still be necessary.

3D models:

• My FP proposal has obvious 3D model (referencing) implications.
• KLC chapter needs complete overhaul. See also KLC: M1.2: Consistency with current practice kicad-website#435

[poeschlr]

To be honest i would like to completely get rid of manufacturer specific QFNs (and similar). This is simply legacy stuff as we did not really have a full naming convention back when these got added (and we did not have an IPC generator either, so we used the datasheet suggested footprint which differed for the same package).

The manufacturer specific names could go into the keyword field. That way they appear if the user searches for them. No need for aliases. The official symbols will always use the generic name derived from package size parameters (so the normal footprint name)

I am also not a fan of using the MO-xxx numbers as most users do not really know that JEDEC namings even exist. The kicad naming convention is intentionally made to be human readable and it should really stay that way. So QFN-xxx and SO-xxx are i feel the best naming option (possibly dropping these strange non standard prefixes and instead including package height) But again something that we could place in the keyword and or description fields.

I also do not really see a benefit in using derived footprints for differing center pad sizes. This is because the center pad size has an influence on the size of the outer pads. (IPC defines the clearance between center and outer pads which influences the heel fillet size)

---

Edit: does KiCad even offer derived or aliased footprints?

[chschlue]

Edit: does KiCad even offer derived or aliased footprints?

Not yet, but that's not set in stone if I understood @stambaughw correctly.

[chschlue]

I also do not really see a benefit in using derived footprints for differing center pad sizes. This is because the center pad size has an influence on the size of the outer pads. (IPC defines the clearance between center and outer pads which influences the heel fillet size)

True. I actually came up with that idea sifting through generator size definitions and then forgot that it doesn't with their output like that.
Semi-OT: The generator might profit from inheriting base size definitions.

[chschlue]

I am also not a fan of using the MO-xxx numbers as most users do not really know that JEDEC namings even exist. The kicad naming convention is intentionally made to be human readable and it should really stay that way. So QFN-xxx and SO-xxx are i feel the best naming option (possibly dropping these strange non standard prefixes and instead including package height) But again something that we could place in the keyword and or description fields.

This only makes sense if the "vulgar" names are top level as well, as would be the case with alias names.
Otherwise, QFN-24-1EP-H0.8mm as you suggest totally makes sense to me, getting rid of mix and match T, W, V, U... prefixes.
We might also want to consider dropping H prefixes for thermally enhanced versions. For QFN, a heat slug is the default anyway and SOIC-16-1EP or TSSOP-24-1EP already says it all better than sometimes prepending H, sometimes not, as is the case currently.

Edit: We should probably use max height because that's all that several manufacturers (and JEDEC) actually specify.

[chschlue]

Addition to my symbol wishlist:
Would it make sense to have some kind of normally-invisible (i.e. only visible in libedit) template-only (abstract, if you will) symbols for things like consistent triangle shapes in Amplifier_Operational, for example, which all implementations in that lib inherit from?

[aris-kimi]

I want to mention symbols that do not have a PCB footprint, this seems like a more appropriate place for this question, something like IECs' symbols for generic electrical designs. Any thoughts??

[chschlue]

3D models:

3D to FP mapping. Proposed at KiCad/kicad-packages3D#280. Launchpad wishlist item https://bugs.launchpad.net/kicad/+bug/1766323 apparently didn't make it over to GL.

[yankee14]

Get rid of invisible power input pins for all symbols except power symbols (such symbols should not create global labels)

@poeschlr I am starting a design and need a 74x series part, and was pleased to see it already exists in the library. I was confused by the invisible power pins. I could submit a PR that fixes the single part I was planning to use according to the KLC? I would also be happy to go through all the 74x series parts and fix them, and submit that as a PR? Or do you guys plan to fix this issue throughout the whole library all at once?

If I were to fix it, I guess the position of the end of the power pin should not move, so it does not disturb other people's existing designs. The length of the pin should be whatever odd length it needs to be to meet the edge of the symbol body. May I make these changes?

[chschlue]

If I were to fix it, I guess the position of the end of the power pin should not move, so it does not disturb other people's existing designs. The length of the pin should be whatever odd length it needs to be to meet the edge of the symbol body. May I make these changes?

The problem with these symbols is that their invisible power pins create global VCC and GND labels, "wirelessly" connecting them to whatever net called VCC or GND you happen to have. Meaning making them visible is enough to break existing designs.
So don't bother with ugly visible power pins, v6 logic symbols may as well have handsome pins.

[yankee14]

@chschlue Ah I didn't realize it was setup like that, that's unfortunate. Should they be made legacy or something? What can I do to fix them?

[chschlue]

Break all the things!
No, seriously, if you want to take up the logic libs, convert them to "normal" power pins.

Cleaning up those libs is a lot of work but fortunately, not many changes are expected during the v5 release cycle.
It may be worth converting them to v6 format even before v5 libs are frozen (on their own branch of course) because the v6 format should be able to solve some issues with the current generic symbols.

We should probably open a separate issue for that.

[evanshultz]

Where we will have new symbols or new libraries to replace existing ones, is there a scheme to capture that? Could we append the existing name with _v6 (so 74xx.lib becomes 74xx_v6.lib) to keep both in the library for now, and then track those all in an issue so we can cut over to the new stuff at the first v6 RC or whenever the time is right? My thought is that it would be nice to have them both available for comparative testing, and having both in the main library at once is easier to do that for all users rather than having branches or a 'legacy' repo and a separate v6 repo.

I assigned myself to some tasks I would like to tackle.

Symbols:

• Update symgen to take advantage of the new file format. Could be a new generator (symgen2?) or a switch that defaults to the new format but can be set to use the old format similar to how some footprint scripts have a parameter to use 'v4 pads'. @evanshultz
• Update check scripts for the new library format.
• Script all logic libraries (4xxx, 74xx, and 74xGxx, along with the IEEE variants) with visible power pins and other fixes/improvements, adding split versions where useful. @evanshultz
• Add scripted DIN 41612 symbols. @evanshultz [https://github.com/Create single- and double-row symbols #2935 and https://github.com/Din41612 symbols kicad-library-utils#332]
• Add/update symbols for standardized interfaces (cards like SIM and SD discussed at TE 2041021 SD card connector #592) like the relays mentioned above to use pin 'names' and not numbers so that a single generic symbol can work for more footprints. @evanshultz
• Consider breaking up Device.lib into smaller chunks since it's huge and it may help maintenance. Perhaps passive and simple parts stay in Device.lib, but we could break out Device_Diode.lib, Device_LED.lib, Device_Transistor.lib, etc.

Footprints:

• Bring over the footprint generator, assuming @pointhi is still willing to contributing it.
• Correct scripted chip package sizes and update footprints. @evanshultz [https://github.com/Use unique and IPC package sizes for R, L, and C, Fuse, LED, Inductor kicad-footprints#2280 and https://github.com/Generate separate C, L, and R chip footprints pointhi/kicad-footprint-generator#438]
• Update BGA footprint generator script to use IPC pad sizes given ball information. @evanshultz [https://github.com/Derive pad size from IPC rules pointhi/kicad-footprint-generator#592]
• Script all gullwing, SON, and BGA footprints.
• Rationalize TI footprints names to one format.
• Update scripted crystals, potentiometers, and any other affected footprints to adhere to proper IPC zero orientation.

This might fall outside the realm of library updates, but it would be great to improve KiCad's included footprint generators. Ours are far superior. This would require interaction with the dev team and probably require script updates to provide a standardized and robust API.

[evanshultz]

I had written the above down over several days and missed the most recent comments above. There has been a lot of discussion about the logic libs already, and two attempts to script them by a couple other contributors. My plan is to pick up from where those initiatives left off and finally get it done. While small manual, incremental updates could be done I don't think that really is going to get us where we need to be so IMO there's little reason to do it.

[chschlue]

Where we will have new symbols or new libraries to replace existing ones, is there a scheme to capture that? Could we append the existing name with _v6 (so 74xx.lib becomes 74xx_v6.lib) to keep both in the library for now, and then track those all in an issue so we can cut over to the new stuff at the first v6 RC or whenever the time is right? My thought is that it would be nice to have them both available for comparative testing, and having both in the main library at once is easier to do that for all users rather than having branches or a 'legacy' repo and a separate v6 repo.

I suggest a v6 branch parallel to master. We can freeze v5 at some point by branching out v5 followed by merging v6 into master, adding *.kicad_sym files and deleting *.lib and *.dcm
That way, we avoid cluttering master up with 74xx_v6.lib and later 74xx_kicad_sym.
Thoughts?

IMO, we need to start some v6 changes before 5.1.7 is released.

[chschlue]

@evanshultz you may want to talk to @yankee14 and take a look at #2738

[yankee14]

KLC wishlist:

1. In previous symbol PR's, I have been asked to put the reference designator on the left side and the value on the right. I think the reference designator should be placed on the right side of components, and the value on the left. This is because the length of the value is fixed and unlikely to change very much, so is unlikely to need to be moved so that the string doesn't crash into pins. On the other hand, reference designators have an undefined length, so they should be placed on the right to allow room for the string to grow as needed during annotation, and reduces the risk of the string crashing into pins. For example, we don't know if the user will need R1 through R9, or R1 through R9999, etc.

[evanshultz]

@chschlue
That's right! The file extension is different. Yeah, that makes things easier whichever way we go.

@yankee14
This was done because the library colloquially put reference on the left and value on the right. Justification can be set for each piece of text so it should be OK to continue this. And it's something to consider adding to KLC, if Rene approves it. That all being said, those text fields are subject to the auto-placement algorithm so it's also worth considering if text placement should be controlled in the library if it's decided that text auto-placement will be used. Just another thing to consider.

And with that, we've definitely derailed the main point of this issue. I should think separate issue would be best to continue discussion on this topic.

[bobc]

Just an FYI: over 2 years ago I added preliminary support to symgen to support the "new" s-expression format. Now that the KiCad code is catching up, I have updated symgen with latest version of spec. It's still incomplete, but the gist is there. There's a CLI option to select it.

Unfortunately I can't test it with KiCad, because KiCad developer didn't follow his own spec! Whether this is temporary code, or Wayne intends to change the spec yet again I don't know. I don't really fancy flip-flopping my code to keep track, so I would wait until the KiCad code is more mature, or at least the code and spec are consistent.

[chschlue]

Symbols

Allow(/encourage/require) LaTeX-style _{subscripted} (and ^{supercripted} when appropriate (probably rare)) pin names.

Ex.

[bobc]

That would require changes to KiCad code, surely this thread is about changes to KiCad libraries (ie data)?

[chschlue]

This is live in kicad-master already.
Besides, who says the lowly library team can't ask the devs for features?

[bobc]

Oh cool. There's a couple of places where I could have used subscripts.

[poeschlr]

I am not sure if this is already recorded. Since version 5.1 there seemed to be a 3d search path feature. I think i requested an explanation of it on the mailing list but never got an answer. We might again look into that one for v6.

[poeschlr]

@chschlue regarding branching i would go the other way round. Branch away version 5 and develop v6 on master. This would be the same way as is done with the source code (I doubt the v5 branch will then get many more changes. I would say we will limit it to fix critical bugs as we really don't have the resources to handle supporting two such different systems).

[chschlue]

@poeschlr for "real" v6 development, of course.
I only suggested we do it the other way round if we were going to start partial v6 transitions like with the logic libs for example (where no substantial additions are to be expected) before we freeze v5.

Whatever we're going to do, I don't think generally accepting PRs against anything but master is going to end well. So yes, whenever we officialy switch over to v6 development, v6 would have to be master.

[poeschlr]

@chschlue I suspect we will freeze the lib very soon assuming the timeline is still to have a releasable version by kicon-2020.

---

Back to topic, the inductor lib does currently not follow the naming convention for all of its assets (a lot of footprints are missing the body size specifier)

[cpresser]

My ToDo-List is focused around symbols

• Rework Memory_Flash commonalize them so we only have one style for all the 8-pin serial flash devices.
• MCU_Microchip_PICxx are quite messy. See MCU_Microchip_PIC18 is inconsistent #2098 But this is a huge project. Not sure I find the time and motivation for that.
• Improve USBLC6 symbols USBLC6 ESD protection diodes #2598

Footprints (not v6 specific)

• Commonalize styles of some connectors (Pin1 marker, PCB-Edge marker)
  • USB
  • RJ45

Misc Tasks

• CI Pipeline for footprint-generator
• PR-Template should include information on when scripting is required
• KLC-FAQ Quite a few things are not explicitly coded in KLC to keep it brief. So having another location to put information on how to interpret KLC and howto handle corner-cases would be nice.

(I will update this post with items when I spot them)

[poeschlr]

It seems micro controller symbols can be massively improved with the new support for pin alternative function capture https://forum.kicad.info/t/post-v5-new-features-and-development-news/15693/252

[evanshultz]

@chschlue
Do you (or the devs) have a wishlist for v6? Several of us have put down what we want to work on, and while I get that we're all volunteers and you gotta take what you get, maybe some direction would be nice. Then perhaps we could divide up that high-level wishlist and then add on our own personal desires.

If there are things which greatly improve the library for users that seems like an area to really focus on and is why I will do the logic library overhaul once we move to GL and we're not all in a reviewing and merging frenzy.

[chschlue]

I meant to open a bunch of (more or less) self-contained issues together with basic triage labels that librarians can assign themselves to so we can see what has to be done and what's covered but haven't gotten around to it yet.

[chschlue]

(Symbols embedded in v6 schematics give us a lot more leeway regarding breaking changes so most leftovers shouldn't have to wait for v7 but we should be done with big disruptions like splitting/merging/removing/reworking entire libs by 6.0 release nonetheless (as far as possible)).

[chschlue]

@KiCad/librarians I have opened issues #2984 thru #3082 for every lib and also partially started assigning librarians I believe have volunteered at some point and/or are most familiar with the matter.
Please don't feel offended by any errors or misjudgments. Feel free to assign/unassign/reassign yourselves as you see fit.

Note that assignees are not expected to do all the work on their own but it would be great to have some kind of steward for every library.

[chschlue]

I think I added all symbol wishes that came up here to the appropriate issues (which may be converted to GL epics later.)

Please do the same with any new ones. Closing.