search

KiCad / kicad-symbols

Official KiCad schematic symbol libraries for Kicad 5
https://kicad.github.io/symbols
Other
703 stars 745 forks source link

The version 6 wishlist #2705

Closed poeschlr closed 4 years ago

poeschlr commented 4 years ago

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 commented 4 years ago

My first ideas: symbols

footprints

calebreister commented 4 years ago

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

Symbols

Footprints

3D Footprints

poeschlr commented 4 years ago

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 commented 4 years ago

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:

poeschlr commented 4 years ago

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 commented 4 years ago

Edit: does KiCad even offer derived or aliased footprints?

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

chschlue commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

3D models:

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

yankee14 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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:

Footprints:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

yankee14 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

Symbols

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

Ex. IR2111

bobc commented 4 years ago

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

chschlue commented 4 years ago

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

bobc commented 4 years ago

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

poeschlr commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

My ToDo-List is focused around symbols

Footprints (not v6 specific)

Misc Tasks

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

poeschlr commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

(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 commented 4 years ago

@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 commented 4 years ago

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.