-
Notifications
You must be signed in to change notification settings - Fork 956
RFC - Symbol Naming Guidelines #1398
Comments
AFAIK there is no such push from above to have atomic libs. There is a push from all of us to have libs that are at least consistent and have a solid policy behind them. To me, a fully atomic library part would have exact order codes, temperature rating, etc. This would quickly bloat the libraries. Perhaps with the new library format we could support this using "VARIANT" functionality. i.e. we have a part say MCP2551_SOIC that has underneath it all the possible variants. If we look at the basic requirements for a fully-defined library part, we need the following:
There are some symbols that do not need to indicate the footprint style as there is only a single option. The ADM3053 only has one compatible footprint. This could be added to the library simply as ADM3053 Conversely, a symbol such as the MAX232 is available in different footprints (and different manufacturers!) This presents a more tricky case. It doesn't matter if a part is offered by different manufacturers if the pinout is the same. If we go with using standard package suffix, we could e.g. have
However if the pinouts vary between manufacturers, you could prefix the manufacturer name:
I do agree (mostly) that such a format allows for greater generalisation and means that the library policy is much easier to write and police. e.g.
However, as @evanshultz notes:
In the case of the MCP6566 (and there are many cases like this). I would suggest the following unique symbols
(This is specific to this particular case. In cases where there is ambiguity there would need to be some discussion by the librarians - that's why we're here!). For devices that have truly incompatible footprints, then you would have to add the footprint suffix. e.g.
I am coming around to the idea of having a standardized footprint name and then letting the user select the exact MPN when it comes to BOM selection. What do ya'll think of this summary? |
Looks like everyone is asleep - my turn again! I much prefer to organise the libraries by function first (much as it is done currently). I think there should be more granularity in the libraries e.g. We should map out a set of library files that we want, based on the current set which is mostly good. When libs become too large, or start to specialize too much, we should break them off into (e.g.) manufacturer subsets. e.g.
e.g.
i.e. function takes preference over manufacturer. As part of this, the contents of each type of library needs to be identified. Currently there is no way of doing this natively in KiCad. I would like to see a description next to each library. That's one for the developers, I think. TL;DR - libraries should be sorted by function Note: Currently we have a lot of libs such as |
Variant NamingIt pays to consider a specific case when thinking about how footprint variants are handled. Let's look at the LTC3621. This is a DC-DC switching converter with: Two package types
Three output voltages
Two switching frequencies
Two temperature ranges
That's a lot of combinations. I don't think there exists a set of math equations to even solve for that. If a user wanted to go ahead and add an alias for each of those options, that would be a great benefit to the libraries. But, I don't think that every contributor would want to do that. And, where do we draw the line? Bare minimum, there needs to be two symbols in the library for the LTC3621 part, one each for the MSOP and DFN versions. We could either name them according to the manufacturer naming:
Advantages
Or
Advantages
Either choice requires the same number of library symbols. I think it is easier to enforce that each symbol only gets a unique symbol for each footprint, not for the other options (e.g. frequency / temp / etc). There are millions of combinations and either we draw the line in the sand here, or we argue about it on each submitted PR. At the end of the day, a user can select the LTC3621 symbol, insert into the schematic, and then rename it to LTC3621IDCB#PBF if they so choose. |
If we want to make a concerted effort to improve the maintainability and documentation for the libraries, we could make a kicad.github.io page. I have integrated these for a couple of projects and they're very nice to use. Why?
Versioned Library ReleasesEach library release could be added to a "Downloads" page - for improved user visibility. This means that users can download a snapshot of the libs at a stable release point. Library BrowsingWe could (with the help of scripting) host a directory-tree-view of the available libraries. Github page are statically generated but we could rebuild them each time a PR is merged into the symbols or footprint libraries. Then we could generate example images of each footprint / symbol and present them as an overall snapshot of what is in the libraries at any time. DocumentationWe need a lot more documentation on the following:
Each of these could have its own page with in-depth examples. Thoughts? |
Good morning around the globe @SchrodingersGat (i.e. yes I was asleep ;-) I mostly agree with what you write above, but with a preference for not using the manufacturer package naming (so we achieve even better stdnardization over the whole lib). Still a few comments on some of the topics:
What do you all think? JAN |
Hi all ! Since all these modifications implies changing libraries and parts names, i think that it should be a system to forward changes made in the libraries to schematics so, when a user load a new version of the libs he won't run into losing all his symbols in already existing schematic and keep pointing to a "real" symbol (not a cached one) but i think that it's for the dev team... I agree with @jkriege2 with the MCUs libs, and i would suggest that those parts stay atomic since you'll often look for a specific MCU. Plus, i also think that if we add the package whithin the component name, we should add the standard one if there is one. Therefore, i think that the manufacturer package name should be stated somewhere if needed to clear any misunderstanding, in the description maybe. PS :
I believe that it's just about some good old multiplication here 😛 |
Hi @suzizecat ! I don't think having such a forwarding will be possible ... the cached symbols are there exactly for that reason!
Which should we choose as the "standard" package, e.g. for an LM317??? Best, |
PS: I will try and come up with an initial proposal for lib-names until tomorrow evening or early next week (or maybe even earlier ... I already started on that) ... maybe we can go on dicussing based on that? |
Sadly a lot of people to not archive the cache lib (We get a lot of questions regarding that over on the forum.) |
I would vote for either full package granularity, where possible. It's a step towards atomic parts but without requiring each individual variant. From a design perspective, for bespoke ICs you generally pick the package first (or early in the design). I would also rather have
This would be great but I fear it will not be possible at least not for a while. We should to the best with what we have, and plan for future advancements with the new library format.
This is a good idea, I think it will be hard to make a ruling on this (but I am happy to be proven wrong!). We could step back and say that one-symbol-per-package-variant is all that we will accept too What we should work towards here is not a complete rework of the libs, but a migration path towards the new features of the improved libraries. If we implement a semi-atomic part strategy where each package variant has its own symbol, then when the new libraries come we can add each variant then - and we'll be well prepared for it.
Ah, you got me! |
Renaming librariesAny major change should be held off until the next stable release (5.0 would be perfect). I would ideally like to see the new library files implemented at the same time as merging the footprints. Then we could have the following repos:
/kicad-library repo would stay for a while (at least a year) marked as deprecated and not accepting PRs - for legacy requirements. Same with all the .pretty repos
That would be great, and well appreciated - however bear in mind my points above - we cannot enact major change without major thought :) |
Symbol Naming (Reprise)I am looking again at the LM317 datasheet. If we are to create a new naming scheme for package variants, I still think this introduces an unnecessary level of complication. On p1 of the datasheet we see four unique part numbers:
Here we notice a few things
Further, a brief look at some other packages shows that not all manufacturers conform to the same package naming. What TI calls a TO-263, another may call something different. So we have to encode some scheme which can accommodate this. If the datasheet says one package but we use a different one, that's going to lead to confusion, at a minimum. As a product engineer, how do I actually pick the package variant? I (personally) want to go into the selection window and see an option that directly matches the datasheet. I don't want to have to match up the datasheet with yet another naming scheme. Yes, the manufacturer naming schemes are all different, and all terrible. But let's not add another layer of confusion! For 'generic' parts, I really agree that we should use a standardised suffix such as The LM317 example above highlights one big problem with encoding our own scheme. In that datasheet there are two TO-220 packages with slightly different physical dimensions. To encode that (any many similar violations) we would need to allow for such names as A user trying to select between the two options based on such names would then have to go back and cross-check with the datasheet anyhow! Using the datasheet naming scheme we avoid that entirely. |
First of all you should answer a simple and fundamental question: "If KiCad standard libraries are for hobbyists/one-time-users or (semi-)professionals?". Keeping in mind some words of Wayne (somewhere on dev mailing list), KiCad should acquire more attention of professionals. |
Professional use is what we are targeting. Hobby users will benefit from using quality libraries, whereas professional users will reject hobby-grade libraries out of hand.
We are not going to support all R/C variants for example. Maybe one day, but that would require a much larger library team. I see the value of atomic parts, and know personally the calamity that can be caused by incorrect part specification. This is always the responsibility of the person designing the schematic. The KiCad standard libraries should be a launching point for professional design with KiCad. The higher standard we hold the libraries to, the more people will make use of them and contribute back to them.
It does! I am of them - which is why I am pushing to have the libraries be improved upon greatly. |
The major argument for not specifying every single part variant in our libraries is thus:
It's all a matter of effort to reward. I think the discussion on this issue thus far is trending towards a workable solution somewhere in the middle of "useless libraries" and "too much work". |
The LM 317 also demonstrates a big problem with using the manufacturer suffixes (I copied this from one of the other discussions): Here's an example:
Naming scheme:
So, how do we work with this? Is LM317 then a generic part, or do we add all variants? What happens if we have a part that is only later also produced by another manufacturer with other suffixes? Do we add those too? If we say assigning the correct MPN is a task of the lib-user at BOM stage, then adding generalized suffixes Note: I'm more the hobbyist and software-developer ... and I clearly see the benefit in grouping stuff as good as possible (to minimize work and ensure manageability) ... but if that approach is totally unusable to a professional electronics engineer let me know. In that case I feel that also the way that KiCAD is taylored towards a certain process would need to change. Currently it is designed (as I understand it), so you first design the schematic from more or less general parts and only then select the packages, when designing the PCB ... Best, |
Hi @jkriege2 ,
You misunderstood me when i was talking about "standard FP", i wasn't talking about a "most usual package" but about the standard denomination, reffering to the "Variant Naming" post of SchrodingerGat For my part, i used KiCAD as hobbyist and now in a professional way, but in a pretty small structure. I got to say that i was stupidly caught in using an IRF9Z34N (a mosfet transistor), didn't found the right pin mapping in the datasheet and assumed it was GDS like other transistors i found when it was GSD (or something equivalent). That was my absolute first real design and it took me 2 mounth to find out where the problem was... For the LM317 problem, i would think to add the name of the manufacturer somewhere in the part name, but that wouldn't nice to maintain (at all) since it will be hard to have all manufacturers... Best, Julien PS : |
@jkriege2 the LM317 was a poor example choice (on my part) as this is a prime example of where the footprint suffix works really well. The LM317 (and similar common parts) should be used with a suffix like However any footprints where there are multiple pinouts in the same package cause issues. I really do not want to have naming conventions like Let's consider another example - the PIC18F2xkx0 series. Here the PIC18F2xK80 device is available in SSOP/DIPSOIC with the same pinout. This symbol is complicated enough that we don't want to have to duplicate it for each item. But how do we name it? Perhaps this problem can be held off until we have the ability to have variants with different footprint association? It becomes a moot point at that stage! With the knowledge that in the future we will have to port our libraries over, and that we will have much more powerful library features, I propose the following:
I will agree to the above if we can come up with a solution for a naming convention that handles the aforementioned issues: a) How to deal with a part that has multiple pinout options for the same package? |
Hi! @SchrodingersGat
As the push for atomic parts seems very strong to me (at least what I see from these discussions), you suggested some allowances above ... but I have no clue how we could formulate them in a concise way and prevent too much clutter ... Did you have a set of concrete rules in mind (especially when to use them exactly)? Best, |
There is one other practical issue, KiCad hangs when there are "too many" components in a library. I don't know what the upper limit is, but I tried adding 130,000 atomically defined resistors and that broke KiCad. I cut the number down to about 5,000 and that seemed ok. That shouldn't stop us from organising the libraries the way we want, just bear in mind we may need some fixes in KiCad code to improve scalability if we start to create really large numbers of components. |
Okay, slightly off topic here, but is there a reference on the actual file formats and capabilities of S-expression and SWEET fileformats for Kicad 5.x? The closest I could get to was https://forum.kicad.info/t/changes-to-eeschema-and-its-file-format-any-info-dates/3297/10 without actually going into the code. |
@gauravjuvekar here's what I have:
From the sounds of things there is a large amount of code that has been written but is hidden from the development branch for now. |
How should we handle part naming until this issue is decided? |
@jkriege2 Also, about manufacturer names. |
@gauravjuvekar I kept some letter-casing, as usually changing it in a GIT or SVN repository can be a real pain ... especially for windows ;-) About the others: thanks, I will fix those JAN |
Regarding the long Regard, the library list above, Jan, I will make a few edits. There are areas of the current and proposed library that appear to have gotten attention and other areas that need help. I suspect because we have different backgrounds and my experience is in a different place. I also dislike having a library named I think we should look at this more like a _ system, where we group parts in two levels. For example, classes might be
I'm not saying the above is better but just providing another idea about how things could be grouped. I feel like writing it out is easier to understand than a bunch of text. |
A bit of work done on the list above, with notes. Perhaps this should actually be a wiki page instead of buried within the body of an issue? To expand on what I mentioned above, I think all IC libraries should be prefixed with |
Agreed, the KiCad library management tools are a bit lacking. Personally I think the best approach is to improve the internal tools, otherwise it's duplicating effort. We could potentially look to expand the python functionality (currently only in PCB side) that way we can easily extend library tools with simple scripting. |
@jkriege2 thanks for your library suggestion above - I am opening a new issue to discuss reorganisation of the libs, and I will rename this issue as you suggest. Please move any discussion to the library rearranging to the new thread |
> (although this breaks the workflow behind KiCAD) I disagree - the workflow behind KiCad allows users to use an atomic part, or to select the footprint from a list of filters. Both are acceptable, and there are cases where each option is the "best" option > Which components are generic needs to be checked/defined carefully during review by the librarians !!! Definitely. But it's not an undefined problem - there are obvious cases where a MPN matches multiple manufacturers, and obvious cases where a part is specific only to a single manufacturer. It is the cases in the middle that will require attention. As these edge cases become apparent, we can update the contributor guidelines, learning more as we go, and refining the process accordingly. The world of electronics engineering is way too diverse to be able to have a single convention:
(Pick one! :p ) |
OK @SchroedingersGat will you make the required updated to KLC? cu |
I'd like to sum up what I think I understand above. By repeating it in my own words I will hopefully be sure that it's all captured properly in my mind. This is mostly, I believe, Jan's info above with examples added. Please add more contributions or breaking cases or categories I've missed. I've been working to clean up linear.lib so please forgive me for being focused on the problems found with opamps and comparators. A lot of notes and questions can be found at #1081. There are several categories of parts. In all cases, some general rules are followed:
Generic (?), compatible partsThe first class is for parts that have several vendors supplying the same part, but the base MPN is sufficient to capture the part type, it's package, and it's pinout. This is the simplest case because a single symbol will cover a large number of possible MPNs. Examples:
Different part numbers for different packagesThis class of part is a generic part made by a number of different manufacturers with seemingly equivalent parts, but which don't share a full MPN for the same pacakage. These part will named using the base MPN followed by a suffix of the base package type. Without adding this extra info, it would be impossible to differentiate the package type or would result in a huge number of ALIAS entries to cover all possible MPNs (which in some case could result in the same MPN from different vendors designating a different package). Many basic opamps, regulators, and comparators fall into this category since these are common parts created long ago and multiple-sourcing has become critical. Each different package type, even if pinout compatible, will be an ALIAS to avoid long symbol names. An underscore will separate these sections of the symbol name. Examples:
Single manufacturer with fully specified package/pinout/type/etc.This category is for parts which come from only one company and are unique in the library. In some cases, a manufacturer will offer the same die in the same package but with different pinouts. In this case, the full MPN also differentiates these parts. Examples:
|
@evanshultz I think you have done a fine job of outlining the approaches. I have been trying to think of a way to define this in a brief fashion (for the purpose of the KLC / FAQ). Your input here helps with this. There will be some edge cases where we will need to decide how to handle symbols but for the most part, I think the approaches you have outlined above are very good. |
Couple of questions ...
Presumably other variations (e.g. voltage output of regulator) are to be handled with aliases, not
Removed, or replaced with |
I think my question got answered here ... #1474 (comment) Looks like all operational parameters will be wildcarded / ignored and aliases will not be used for them. |
I'm not so sure ... did we come to a conclusion on that topic? JAN |
I don't think that a general removal of all operational parameters is in any way sensible or helpful.
Of course adding all the required aliases can make the generation of components more time consuming. But most of this comes done to expanding a parameter matrix into a matching part number and description. This could be simplified a lot with better tools to generate those by filling variables. |
In your example (TPS20xx) nearly no aliases will be required. As far as i see a lot of the mpn numbers will need to be symbols anyways because they have slight differences in functionality, pin numbers, ... I don't think anyone expects kicad to be a complete catalog for all possible parts. I agree that it would be nice to have a better search functionality though. Just take ti as an example. Nearly all TI parts exist in industrial specification and in automotive specification. |
I don't want to argue about automative specification, increased temperature ranges, etc. These are really just minor modifications and should be globbed as already discussed. But current / voltage ranges, for examples for regulators, are something completely different in my opinion. I would like to see them in the library as an alias. Maybe give the create the option to add them if he wants to go for the extra mile. |
I thought a bit more about this issue and got an idea which could fit both approaches (try to be generic vs. be as specific as possible). It would require changes to the kicad code, which I would be interested to do. But I would like to hear some opinions about the idea first. The rough idea is to allow for a hierarchic structure of schematics. This would allow to have a generic element as a node, where the specialised variants would be leafs below that node. This would allow to choose the generic node if one doesn't care, while still giving the possibility to use the specialised variants (same is true for library maintanance, if one doesn't care about the specialisations one can leave them out/add them later). To increase the usefulness of this approach I would like to add an optional footprint field to the alias description in the dcm files. This would allow an alias to override the selected default footprint. Then it is easy to have several variants which only differ by the footprint, i.e. SMD size. I think the hierarchy could be implemented easily by adding an optional field to the descriptions which can reference a parent. This makes the current description a child of the specified parent. |
@lorem-ipsum that's a great idea - and is already defined as part of the planned .sweet format! Essentially any symbol can "inherit" from a parent. So the idea of generics and variants will be supported right out of the box :) |
@SchrodingersGat cool, that is great to hear. That saves me some work ;-) |
This issue follows on from #1386
Some references:
The text was updated successfully, but these errors were encountered: