Closed SchrodingersGat closed 6 years ago
@evanshultz - Is there a desire by Wayne or someone else to make the KiCad library atomic? If there's a future plan then it might be good to get ready now. The references above don't talk about that and I did hear Wayne mentioning at FOSDEM that there could be plugins for Digi-Key or other vendors in the future. In that case, the KiCad library would only need to be (but wouldn't have to be) generic parts.
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.
Each device must have a unique symbol for each possible package, where the package name is appended to the generic MPN
However, as @evanshultz notes:
Where is broke down for me (unfortunately, I was happy until then) were when I was fixing up linear.lib and got to parts like MCP6566 where the same package can have different pinouts.
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. adc-dac.lib
becomes adc.lib
and dac.lib
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.
display.lib
<- general display symbolsdisplay_7seg.lib
<- 7-segment displayse.g.
linear-reg.lib
<- linear dc-dc regulatorslinear-reg_Texas.lib
<- Texas Instruments linear regulatorsi.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 Microchip_pic18mcu.lib
- I would argue that this too is an example of sorting by function!
It 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?
Each 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.
We 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.
We 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:
LM31L_TO92_SOT89
+ LM317L_SOIC_TSSOP
).ICs/Linear/OPAMP
or ICs/Linear/Regulators/Positive
and KiCAD could use that info to populate the component tree with not only two layers (lib+devices), but several layers, built up from the tags, until then we should ensure the file-names are at least remotely human-readable, as the sorting of filenames in the tree already gives such a structure ... only flattened out.Microcontrollers_Atmel_megaAVR
Microcontrollers_Atmel_tinyAVR
Microcontrollers_Atmel_classicAVR
Microcontrollers_Atmel_AVR32
Microcontrollers_Atmel_ARM_SAM3
Microcontrollers_Atmel_ARM_SAM4
Microcontrollers_Microchip_PIC16
Microcontrollers_Microchip_PIC18
Microcontrollers_8051
Microcontrollers_8048
Processors_Z80
Processors_AMD_x86
Processors_Intel_x86
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 :
That's a lot of combinations. I don't think there exists a set of math equations to even solve for that.
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!
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.
Which should we choose as the "standard" package, e.g. for an LM317??? and: So we should keep a double-list of packages? Waht if a symbol stands in for several manufacturer packages? List all those MPNs in the description?
Best, JAN
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 think such a major change should be done with the introduction of kicad 5.x. As a solution we can for example branch the lib and get a new 5.x branch (or branch away a 4.x branch and keep the master branch as the branch where PR are merged into.)
@jkriege2
- We should also discuss how to wrok with parts like LM317L
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 LM317L_T092
and LM317L_SOT89
rather than LM317_TO92_SOT89
- it quickly becomes messy. What if it matched three footprints, or four? Would we have LM317_TO92_SOT89_SOT23-3_TO-220
?
- I like the idea of breaking down the libs ... ideally, if KiCAD would support a description per lib file,
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.
- We should try and come up with a list of features (maybe component category-dependent) for which we would like to see variants
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.
That's a lot of combinations. I don't think there exists a set of math equations to even solve for that. @suzizecat I believe that it's just about some good old multiplication here :stuck_out_tongue:
Ah, you got me!
Any 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
@jkriege2 - 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?
That would be great, and well appreciated - however bear in mind my points above - we cannot enact major change without major thought :)
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
TO-220
options available (how would we encode that?)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 _SOT-23-5
(etc). But where we are matching to a particular manufacturer datasheet, we should use their numbering.
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 LM317_TO220_VariantA
or LM317_TO220_W10.36mm
.
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?".
The hobbyist will be happy when you use for example: LM317L_TO92
, LM317L_SO8
(with correct pin association).
The professionals will be very angry, because they need a real, manufacturer part number for their BOM's. Even if they need a simple capacitor SMD 1206 100nF they need full manufacturer code, because using X5R type instead X7R may collapse their project.
Keeping in mind some words of Wayne (somewhere on dev mailing list), KiCad should acquire more attention of professionals.
First of all you should answer a simple question: "If KiCad standard libraries are for hobbyists/one-time-users or (semi-)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.
The professionals will be very angry, because they need a real, manufacturer part number for their BOM's. Even if they need a simple capacitor SMD 1206 100nF they need full manufacturer code, because using X5R type instead X7R may collapse their project.
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.
KiCad should acquire more attention of professionals.
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: LM317
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 _TO92
... still seems to me to be the only managable variant unless we want a large set of rules on how to handle such components ...
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, JAN
Hi @jkriege2 ,
Which should we choose as the "standard" package, e.g. for an LM317???
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 do love having atomic parts in KiCAD because you're sure that your part got the right pin mapping and that you will have the right FP for it.
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... It was totally my fault, but what i'm thinking is that it's waymore conveignent when you can have your exact component in the lib since you wont do that kind of (pretty stupid and unprofessional since i was hobbyist) mistake.
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 : I got a sneaky trick for ST datasheets, you should try right click the link pointing the DS and use "Copy the link address" (or equivalent) rather than going into the PDF and copying the address bar, then you got http://www.st.com/resource/en/datasheet/lm317.pdf for the LM317 which is way more convenient than their insanely long address...
@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 _TO-220
(etc) as otherwise we need to maintain individual LM317 parts for each manufacturer. Your scheme makes the most sense in this example.
However any footprints where there are multiple pinouts in the same package cause issues. I really do not want to have naming conventions like _TO-220_Variant-B
(or similar). Such names do not contain enough information to identify the correct footprint. We need a clear direction for these edge cases.
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? PIC18F2xK80_SSOP_DIP_SOIC
? This looks very messy to me..
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:
We mandate that new parts must be "atomic" (one symbol for each footprint type) but beyond that they are generic.
Part variants should be named in a fashion MPN-BASE_PKG
e.g LM317_SOIC
or MAX232_DIP
These base parts allow users to drop into the schematic and then insert any precise MPN (or internal part number) that they want.
When the new library format comes around, we can add variants with multiple parameters, etc, etc
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? b) How to deal with a part that matches multiple footprints with the same pinout?
Hi! @SchrodingersGat
MCP601_SOT23
and MCP601R_SOT23
... They list them as MCP601 and MCP601R on the first page of their DS, i.e. the R can be interpreted as part of the base-MPN... But I don't know how other manufacturers do that ...PIC18F2xK80_SSOP_DIP_SOIC
: yes that's messy, I ran into the same problem, when rworking regul.lib. There are already some symbols there that use this nomenclature ... it's far from perfect, but does what I felt was intended by the KLCs that stood at that point.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, JAN
@SchrodingersGat
The major argument for not specifying every single part variant in our libraries is thus:
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? (I have a few PR where the "new" style with MPN differentiation is used and some where _package is used.)
I would propose to hold the PRs until we found a decision (hope we don't need weeks for that ... but currently it seems that the proposal of @SchrodingersGat is not too bad and opens a good road towards the new lib-format. Also the numberof-of-symbols-point of @bobc seems a very valid point to care for at the moment.
Maybe it will even become possible to simply add variants to that as a simple table (spreadsheet-like) that would make management very simple.
Would holding off be OK for you?
Best, JAN
For me yes, for the contributors i'm not so sure. I guess if we are open about why we currently wait with merging their contribution, they should be ok with it.
I hope so ;-) ... What do you think on @SchrodingersGat 's proposal above?
The TPS74401 part has been mentioned in another thread. Here's another example of a part that would complicate our rules.
It has three package options:
a) TO-263 b) VQFN (5x5mm) (RGW package) c) VQFN (3.5x3.5mm) (RGR package)
TI names these as follows:
a) TPS74401KTW b) TPS74401RGR b) TPS74401RGW
How would we name them?
a) TPS74401-KTW_TO-263 b) TPS74401-RGR_QFN c) TPS74401-RGW_QFN
i.e. MPN-SUFFIX_PKG
But this adds another step (the TI names already fully define the part / package combination).
Would you be ok with separating the concepts of generic parts (e.g. LM317 / LM7805) and manufacturer parts? I don't think we are going to have one rule that fits everything. If we try to squash all use cases into a single naming scheme, it's going to mean compromising the usefulness on many fronts.
Let's look at examples of various 'levels' of genericism in the libraries currently:
There are situations in which each naming convention makes sense.
Maybe, instead of trying to force every symbol into a single convention, we should try to generate a comprehensive set of library guidelines that better explain the different types of symbols that exist and are allowed in the library?
Here's what we currently have in the library FAQ.
@SchrodingersGat For the MAX3035, i'll say that we should have only one symbol that will fit all necessary FP (it may be what you wrote, but i prefer being clear) .
For the TPS74401, if tbe pin mapping isn't equivalent, i would rather use the MPN without suffix (TPS74401KTW, in example) and write the package in the description since you will have to use the MPN at a certain time anyway...
One thing that will really help is the ability to actually search by footprint in the component selector window.
I thought this was possible, but apparently not.
I have just submitted a patch to allow filtering by footprint text.
This means that we don't have to mandate that the footprint name is repeated in the description, at least for components that have a default assigned foorprint.
Well it seems we always come back to full MPN ... I'm not that happy, but if it seems the best option, why not stick to this (gathering from all your proposals above):
x
(lower-case x). Also here we require package-type granularity (+ possibly parameters like voltage for regulators, or target temperature for e.g. temperature switches).
These rules should work, but they require more work from the reviewers/maintainers to keep the lib manageable.
What do yout hink? JAN
probably we should move to script generated symbols for many parts, which use for example a csv file for specification. This could allow us to simplify adding new parts and managing existing ones
yes that would be great ... especially for standardized stuff like TTL/CMOS, regulators and OPAMPS ... but it will maybe make contributions from the commmunity harder to manage ... if someone provides a new OPAMP ... does one of us recode it in thet scheme, or do we require contributors to use those tools?
Maybe we could persue such stuff for limited cases?
JAN
Here's a first proposal for future libs. Please feel free to edit within this post ... or should we rename this issue to IC Naming Conventions within Lib
and open a new one for this organization discussion?
In this post I'm trying to come up with a list of libs that we could use ... Everybody: Please add/edit what you think should be there ... You can comment behind every entry on that specific lib
connectors.lib
(formerly: conn.lib
)devices.lib
(formerly device.lib
)elec-unifil.lib
motors.lib
power.lib
pspice.lib
relays.lib
switches.lib
graphic_symbols.lib
logo.lib
mechanical.lib
diodes.lib
(formerly: diode.lib
)ESD_Protection.lib
transformers.lib
(formerly: transf.lib
)transistors.lib
triac_thyristor.lib
valves.lib
displays_lcd.lib
(formerly: display.lib
)displays_led.lib
(formerly: display.lib
)opto_leds.lib
(formerly: leds.lib
)opto_photodetectors.lib
(formerly: opto.lib
)opto_coptocouplers.lib
(formerly: opto.lib
)opto_diverse.lib
for all that fit nowhere else (formerly: opto.lib
)sensors_temperature.lib
(formerly: sensors.lib
)sensors_magnetic.lib
(formerly: sensors.lib
)sensors_current.lib
for current shunts, isolated current sensors, ... (formerly: sensors.lib
, linear.lib
, ir.lib
)sensors.lib
For all that fit nowhere else Should we split this a bit more?ac-dc_module.lib
complete AC-DC OTS supplies (formerly ac-dc.lib
)dc-dc_module.lib
complete DC-DC OTS supplies (formerly dc-dc.lib
)smps_controller.lib
SMPS IC with external switch (formerly ac-dc.lib
, dc-dc.lib
)smps_converter.lib
SMPS IC with internal switch (formerly ac-dc.lib
, dc-dc.lib
, power_int.lib
)references_voltage.lib
(formerly: references.lib
)references_current.lib
(formerly: references.lib
)regulators_linear.lib
(formerly: regul.lib
)linear_comparators.lib
(formerly: linear.lib
)linear_opamps.lib
maybe also instrumentation amps, difference amps, ... or should we split them??? (formerly: linear.lib
)linear_instrumentation_amplifiers.lib
group with opamps? (formerly: linear.lib
)linear_difference_amplifiers.lib
group with opamps? (formerly: linear.lib
)linear_transconductance_amplifiers.lib
group with opamps? (formerly: linear.lib
)linear_samplehold.lib
(formerly: linear.lib
)linear_other.lib
(formerly: linear.lib
)audio_amplifiers.lib
(formerly: audio.lib
, digital-audio.lib
)audio_specialfunction.lib
(formerly: audio.lib
, digital-audio.lib
)audio_adc_dac.lib
(formerly: digital-audio.lib
)video.lib
analog_switches.lib
adc.lib
(formerly: adc-dac.lib
)dac.lib
(formerly: adc-dac.lib
)codec.lib
(formerly: adc-dac.lib
)adcdac.lib
for front-ends that have both? (formerly: adc-dac.lib
)transistor_arrays.lib
(ULN2803, ULN2003, ...) is this required???relay_drivers.lib
motor_drivers.lib
gate_drivers.lib
(formerly ir.lib
)lighting.lib
battery_management.lib
Power_Management.lib
oscillators.lib
(formerly: Oscillators.lib
)quarzes_filters.lib
(formerly: Oscillators.lib
)timers.lib
e.g. NE555 (formerly: linear.lib
)plls.lib
e.g. NE567 (formerly: linear.lib
)logic_levelshifters.lib
maybe it makes sense to single them out ... (e.g. 5V <--> 3.3V, ...)logic_ttl74xx.lib
(formerly: 74xx.lib
, ttl_ieee.lib
)logic_ttl74xx_Singlegate.lib
(formerly: 74xgxx.lib
)logic_cmos40xx.lib
(formerly: cmos4000.lib
, cmos_ieee.lib
)logic_cmos40xx_Singlegate.lib
(NEW)logic_programmable.lib
general for PLDs, PALs and simpler programmable logic devices ... should we split this up more? (formerly: Lattice.lib
)logic_cpld_xilinx.lib
(formerly: xilinx.lib
)logic_cpld_altera_intel.lib
(formerly: Altera.lib
, now Altera-stuff is sold under the name Intel, but most people still know it as Altera? Thus the double-name ... should we stick to Intel ... and should we split by family?)logic_fpga_xilinx.lib
(formerly: xilinx.lib
)logic_fpga_altera_intel.lib
(formerly: Altera.lib
, now Altera-stuff is sold under the name Intel, but most people still know it as Altera? Thus the double-name)logic_fpga_actel.lib
(formerly: actel.lib
)logic_fpga_atmel.lib
(formerly: atmel.lib
)microcontrollers_8048.lib
for all sorts of 8048-variants ... maybe alternative name microcontrollers_mcs48.lib
microcontrollers_8051.lib
for all sorts of 8051-variants ... maybe alternative name microcontrollers_mcs51.lib
microcontrollers_atmel_avr_classic.lib
(formerly: atmel.lib
)microcontrollers_atmel_avr_tiny.lib
(formerly: atmel.lib
)microcontrollers_atmel_avr_mega.lib
(formerly: atmel.lib
)microcontrollers_atmel_avr32.lib
(formerly: atmel.lib
)microcontrollers_atmel_avr_xmega.lib
(formerly: atmel.lib
)microcontrollers_atmel_arm.lib
ARM-µPs from Atmel ... should we split by family? (formerly: atmel.lib
)microcontrollers_cypress_arm.lib
ARM-µPs from Cypress ... should we split by family? (formerly: cypress.lib
)microcontrollers_cypress.lib
non-ARM-µPs from Cypress ... should we split by family? (formerly: cypress.lib
)microcontrollers_microchip_dspic33dsc.lib
(formerly: microchip_dspic33dsc.lib
)microcontrollers_microchip_pic10mcu.lib
(formerly: microchip_pic10mcu.lib
)microcontrollers_microchip_pic12mcu.lib
(formerly: microchip_pic12mcu.lib
)microcontrollers_microchip_pic16mcu.lib
(formerly: microchip_pic16mcu.lib
)microcontrollers_microchip_pic18mcu.lib
(formerly: microchip_pic18mcu.lib
)microcontrollers_microchip_pic24mcu.lib
(formerly: microchip_pic24mcu.lib
)microcontrollers_microchip_pic32mcu.lib
(formerly: microchip_pic32mcu.lib
)microcontrollers_freescale_hc05_hc08_hc11.lib
(formerly: hc11.lib
, motorola.lib
)microcontrollers_freescale_hc12_hc16.lib
(formerly: motorola.lib
)microcontrollers_freescale_coldfire.lib
(formerly: motorola.lib
)microcontrollers_infineon_c166.lib
microcontrollers_nxp_arm.lib
(formerly: nxp_armmcu.lib
)microcontrollers_parallax.lib
microcontrollers_renesas.lib
microcontrollers_st_stm32.lib
(formerly: stm32.lib
)microcontrollers_st_stm8.lib
(formerly: stm8.lib
)microcontrollers_texas_msp430.lib
(formerly: msp430.lib
)processors_intel_x86.lib
processors_amd_x86.lib
processors_motorola_68000.lib
(formerly: motorola.lib
)processors_motorola_powerpc.lib
(formerly: motorola.lib
)processors_zilog_Z80.lib
(formerly: Zilog.lib
)dsps_texas.lib
(formerly: dsp.lib
)dsps_freescale.lib
(formerly: dsp.lib
)systemonchips_texas_arm.lib
ARM SoCs from TIIf we decide to still have generic libs:
microcontrollers.lib
for parts that fit nowhere else, mini-series, ...processors.lib
for parts that fit nowhere else, mini-series, ...dsps.lib
(formerly: dsp.lib
)systemonchips.lib
SoCs that fit nowhere elsememories_dram.lib
(formerly: memory.lib
)memories_sram.lib
(formerly: memory.lib
)memories_prom.lib
(formerly: memory.lib
)memories_eprom.lib
(formerly: memory.lib
)memories_eeprom.lib
(formerly: memory.lib
)memories_flash.lib
(formerly: memory.lib
)memories_nvram.lib
(formerly: memory.lib
)interface_rs232.lib
(formerly: interface.lib
)interface_rs485.lib
(formerly: interface.lib
)interface_lvds.lib
(formerly: interface.lib
)interface_ethernet.lib
interface_wifi.lib
(formerly: rfcom.lib
)interface_bluetooth.lib
(formerly: rfcom.lib
)interface_zigbee.lib
(formerly: rfcom.lib
)interface_rf.lib
(formerly: rfcom.lib
)interface_other.lib
periphery.lib
periphery_portexpanders.lib
periphery_timer.lib
periphery_rtc.lib
periphery_uart.lib
periphery_video.lib
periphery_network.lib
bus_i2c_smbus.lib
for I2C drivers, isolators, ...bus_usb.lib
for USB hubs, drivers, ...modules.lib
Should this stay separate, or should they be sorted by function?ic_misc.lib
(formerly powerint.lib
)allegro.lib
analog_devices.lib
bbd.lib
bosch.lib
brooktre.lib
contrib.lib
ftdi.lib
gennum.lib
graphic.lib
infineon.lib
intel.lib
intersil.lib
ir.lib
sensors_current.lib
and gate_drivers.lib
)LEM.lib
maxim.lib
microchip.lib
nordicsemi.lib
nxp.lib
onsemi.lib
philips.lib
powerint.lib
smps_controller.lib
and ic_misc.lib
)RFSolutions.lib
silabs.lib
siliconi.lib
supertex.lib
texas.lib
wiznet.lib
Worldsemi.lib
Xicor.lib
zetex.lib
Edit by @evanshultz on 20170709
-useac-dc.lib
, dc-dc.lib
for modules and break out ICs into smps_controller.lib
, smps_converter.lib
-add codec.lib
(replace adcdac.lib then??), ic_misc.lib
(cause we'll have to have one)
-sort ir.lib
, powerint.lib
-I advocate grouping opamps, diff amps, instrumentation amps, OTA, etc all together
-I dislike using "linear" in the name of any libraries beacuse it's so close to the company Linear Tech
-is it necessary to break down opto.lib
so much?
-assuming it's for SRCs/mic preamps/etc, I like audio_misc.lib
instead of audio_specialfunction.lib
probably we should move to script generated symbols for many parts, which use for example a csv file for specification.
I think that is a really interesting idea. We could still accept submissions as either a CSV update or traditional, the CSV can be back populated.
link-service for everybody not aware ... there's this thread on script-generated symbols: https://github.com/KiCad/kicad-library/issues/605
Whilst there is talk about scripting component generation here is an interesting and quite mature project here [www.qeda.org http://www.qeda.org/] that generates a wide variety of components, matching IPC7351 compliant footprints and 3d-models using scripts and derives the base settings from a simple .yaml file. It allows for a 'house standard’ format and a per-project bespoke library e.g. you can specify extended pads for hand soldering and regenerate your footprints to match.
I think a lot of the problems with how the libraries are organised/named could be helped if there were a really good management tool. This could be part of Kicad or could live outside it. How the libraries were then defined would be less important if one had the ability to slice and dice any libraries by device type, and manufacturer and then add relevant data in a table/spreadsheet interface. The current tools are somewhat lacking - Kicad Librarian (https://www.compuphase.com/electronics/kicadlibrarian_en.htm https://www.compuphase.com/electronics/kicadlibrarian_en.htm) is quite useful but could be improved with table editing of selections of components (and could be multiplatform).
Devices in the manufacturer named libraries for example intersil, infineon, linear etc should be more atomic but a more generic version could live in the class library (e.g.,regulators.lib).
JP
On 9 Jul 2017, at 16:30, Jan W. Krieger notifications@github.com wrote:
ref-service for everybody not aware ... there's this thread on script-generated symbols:
605 https://github.com/KiCad/kicad-library/issues/605
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KiCad/kicad-library/issues/1398#issuecomment-313926834, or mute the thread https://github.com/notifications/unsubscribe-auth/AIAyufk_UwpbV67lUxhy7UEK6h9UTdGIks5sMPIjgaJpZM4ORkY7.
@jkriege2
Very minor gripe, but what's with the capitalization of the library names?
battery_management.lib
vs Power_Management.lib
logic_levelshifters.lib
vs logic_Programmable.lib
Oscillators
, Quarzes_Filters
, Timers
microcontrollers_freescale_*
vs dsps_Freescale
Also, about manufacturer names.
dsps_TI
vs microcontrollers_texas_*
@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 _package
names such as PIC18F2xK80_SSOP_DIP_SOIC
, why not force a limit of only one suffix? However, we know that all these parts can share the same symbol by definition, so there could be one symbol and 2 ALIAS. This would also mean only one symbol to be created and maintained in the library and would be more atomic (if we all like that). Of course, this would only apply to parts with multiple manufacturers to abstract away exact MPN when they conflict (like the MC33078 in DIP example I've given and the ones above).
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 sensors
when that's such a specialized group of parts, for example, and then sensors_temperature
, sensors_current
, etc. That just allows things to get messy. I would want more qualification there. A one-level library like diode
is OK with me, but sensors
seems too generic.
I think we should look at this more like a ic
and passive
and transistor
. Here is an incomplete example of how this could look:
Capacitor
Capacitor Network
Common Mode Choke
Conn - Audio - Phono
Conn - Audio - RCA
Conn - Audio - XLR
Conn - Comm - HDMI
Conn - Comm - RJ
Conn - Comm - USB
Conn - DSUB
Conn - Misc - Header
Conn - Misc - Socket
Conn - Misc - Terminal
Conn - Power - AC Inlet
Crystal
Diode
Diode - Voltage Suppressor
Diode - Voltage Suppressor Array
Diode - Zener
Diode Array
Diode Bridge
Display
Encoder
Ferrite
Fuse
IC - ADC
IC - Analog
IC - Analog Switch
IC - Audio - Other
IC - CODEC
IC - Clock
IC - DAC
IC - DSP
IC - Digital - Pot
IC - Ethernet
IC - FPGA - CPLD
IC - Gatedriver
IC - Linear Regulator
IC - Logic
IC - Memory
IC - Misc
IC - Optocoupler
IC - Processor
IC - Reference
IC - SMPS Controller
IC - SMPS Regulator
IC - Transceiver
IC - USB
Inductor
LED
LED Array
Relay
Resistor - Fixed
Resistor - Network
Resistor - Variable
Switch
Switch - AC Power
Switch - Circuit Breaker
Switch - Rotary
Thermistor - NTC
Thermistor - PTC
Transformer - Communications
Transformer - Current Sense
Transformer - Power - Audio
Transformer - Power - Line Frequency
Transformer - Power - Switching
Transistor - Bipolar
Transistor - IGBT
Transistor - JFET
Transistor - MOSFET
Varistor
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 ic
. So ic_smps_controller.lib
and ic_opamp.lib
and ic_interface_rs485.lib
and ic_audio_adcs.lib
. That's the classification I was describing above. It will pull things together at a higher level and give a much better guide for future people to understand the current libraries and for new libraries to be added.
@Gasman2014 - I think a lot of the problems with how the libraries are organised/named could be helped if there were a really good management tool.
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
@jkriege2 - For common ICs that are provided by different manufacturers we use MPNbase[-param]_PACKAGE, where PACKAGE=TO92,SOIC,TQFP,DIP,TO220,... and -param is optional to cover e.g. voltages/ADJ for voltage regulators. If there are multiple package options with the same pinout, we split these to single-package symbols (although this breaks the workflow behind KiCAD) Which components are generic needs to be checked/defined carefully during review by the librarians !!!
> (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 JAN
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 https://github.com/KiCad/kicad-library/pull/1081.
There are several categories of parts. In all cases, some general rules are followed:
x
.x
in the middle of the MPN or ignored if at the end of the MPN.The 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:
BC846
would cover NXP, On Semi, and Fairchild. While there are a number of different package options, KLC states that footprints should be used to differentiate instead of multiple symbols, so the footprint pin placement will allow these to be symbol-compatible.BAS16
would cover a huge number of vendors and packages of this generic diode well. A range of ALIASes could be added as well, such as BAS21
, BAS316
, 1N4148
, etc. to cover for symbol-compatible packages and types. A large range of FPfilters should be given with no default footprint.This 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:
MC33078_DIP
. There could also be MC33078_SOIC
, MC33078_SSOP
, etc.7805_TO220
and could cover MC7805, uA7805, L7805, LM7805, KA7805, NJM7805, etc., all in TO-220 (metal tab or plastic-encapsulated) package. LM340x-5 would be a separate symbol even though they're equivalent and share a datasheet.LM358
and cover the bulk of LM358 parts, while another symbol named LM358_DFN
will cover for ST's unique package. LM358_DFN
will have a default footprint; LM358
will not but it will have an extensive FPfilter selection.MCP6002-xMS
for MSOP, MCP6002-xP
for DIP, MCP6002-xSN
for SOIC, and MCP6002-xMC
for DFN. The first three can all be the same symbol with two ALIASes and no default footprint. The DFN package will require a unique symbol with a default footprint. This symbol for a dual opamp in DFN cannot be an ALIAS for the dual opamp in DFN package mentioned above, because the DFN MCP6002 has the exposed pad connected to the negative voltage rail pin while the DFN LM358 has the exposed pad floating and not internally connected.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:
LPC11U34FBD48311
(note the /
is removed)AD797
. This covers both DIP and SOIC packages as they share the same pinout, so there will be no default footprint but there will be two FPfilter entries. This one symbol also covers the A and B grades of AD797, which the user can hand-modify if they want to add the suffix after placing the symbol on a schematic.MCP6001
, MCP6001R
, and MCP6001U
. A default footprint should be selected for the latter two while the first would have no default footprint but two FPfilter entries as it's also available in SC-70-5. MCP6001U
could also have an ALIAS for LM321.@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 ...
1.
No temperature variants are listed, only the lowest-grade (usually 0-70C) version. Characters in the MPN that indicate temperature are to be replaced with x. Similarly, grades of parts are not listed individually. Grade is replaced by x in the middle of the MPN or ignored if at the end of the MPN.
Presumably other variations (e.g. voltage output of regulator) are to be handled with aliases, not x
? In other words, the current wording in the FAQ still applies? ...
For parts with variations of operational parameters (e.g. voltage output of a linear regulator family), an ALIAS should be created for each variant. These aliases should be named according to the manufacturer datasheet.
2.
Illegal characters are removed and ignored in symbol names.
Removed, or replaced with -
? Taking LPC11U34FBD48/311 as an example, it might be more readable and recognisable as LPC11U34FBD48-311
rather than LPC11U34FBD48311
.
Presumably other variations (e.g. voltage output of regulator) are to be handled with aliases, not x?
I think my question got answered here ...
https://github.com/KiCad/kicad-library/pull/1474#issuecomment-319298985 https://github.com/KiCad/kicad-library/pull/1474#issuecomment-319307152
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.
x
as a wildcard (regexp .
).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.
This issue follows on from https://github.com/KiCad/kicad-library/issues/1386
Some references: