In a previous post, I discussed two approaches to Kicad library organization. Here, I will go into detail on how I’ve set up my libraries, which use the atomic parts paradigm. Remember: the goal here is to save time and effort. With atomic libraries, you research and vet all parts once, at the time they are put into the library, instead of doing it for each part after completing the layouts for each design.
The Master Parts List
Before we can put parts into a library, we have to know what parts we want to put into the library! Sure, that’s a tautology, but it’s also true. And it implies that we must have a scheme to keep track of parts.
So, what, exactly, is a “part” (or “component,” which we will use synonymously here)? Simple: it is anything that we want to use in a design. Generally, that means the usual electronic bits (resistors, transistors, op-amps, etc) as well as mechanical parts (standoffs, screws, even enclosures) and things that complete the design but don’t get soldered to a board (external power supplies, user manual). All of these things are kept in a Master Parts List, and everything gets a Company (or House) Part Number. This is all for the convenience of the whole organization: engineering needs to know what parts are allowed for use in designs, purchasing needs to know what to buy, assembly techs need to know what to put in kits, and so forth.
A master parts list can be maintained in a system as complicated as an enterprise-resource system, or in a simply MySQL database, or even as a spreadsheet. A minimal master parts list should contain the company part number (the key), a vendor name, that vendor’s part number, and a description. Nice to have, especially for keeping track of inventory, are entries for quantity on hand and estimated cost. My parts list also includes which library the part lives in, the footprint, and the footprint library associated with the part. My master parts list “database” is nothing more than an Apple Numbers spreadsheet.
A part numbering system
My “company part numbers” follow a simple scheme. It’s best explained with an example: A-1000-1 where:
- A is a letter indicating a category (ICs, resistors, capacitors, transistors, mechanical parts, electromechanical parts, etc).
- 1000 is a part number within the category, which distinguishes parts in the category and simply increments from the previous (1000 is the first part in the list, 1001 is the second, and so forth). For some categories, the part number indicates the part “family.” More on that below.
- 0 is a numeral indicating part-number “variant.” A variant is where most of the parts sharing a part number are the same, but there is one (and only one) difference, such as package. For part “families,” this is used to indicate the value.
My categories include A for ICs, B for resistors, C for capacitors, D for transistors, E for diodes, F for electro-mechanical (switches, encoders, connectors) and so forth. My category G is for mechanical parts, such as screws, knobs, light pipes, enclosures.
Footprint libraries
My footprint libraries, all in the .pretty format, are broadly organized by category, and each library name is prefixed with asp_ to avoid collisions with other libraries. Most footprints have an associated 3D model, where I could find one. There is otherwise nothing non-standard about them.
Schematic symbol libraries
My schematic symbol libraries, all in the Kicad 4.0.x .sch format, are broadly organized by category, and each library name is prefixed with asp_ to avoid collisions with other libraries. None of the symbols have hidden power (or any other type) of pin. All parts have a useful description.
All symbols are for atomic components. This requires that they have a preselected footprint, and the footprints are in my libraries. A part called OPA551PA, which comes in the DIP-8 package, has its Footprint field filled with asp_ic:DIP-8. Also, each part must have a custom PN field, and it is in this field that I enter my company part number.
Yes, this means that each dual op-amp and each transistor and each whatever in the library will have essentially identical symbols. A reasonable response to concerns about this is, “So what!”
Naming the part symbols.
A simple requirement, yes? For most things, yes. ICs tend to be straightforward in this regard. Because the package is defined with atomic parts, the name of the part in the library should reflect it. Thus, my library has both LM317T (in the TO-220 package) and the LM317EMP (the SOT-223 package). These are, of course, the TI full part numbers, which encode the package type. The assumption is that the engineer has read enough of the data sheet to know the package codes so s/he can choose the desired device. The device description should indicate the package, so it’s obvious, and post-4.0.5 nightly builds include the footprint in the schematic symbol browser, so there shouldn’t be any complaints about the part number and “remembering what the extensions mean.”
Connectors and switches and the like are where things can get ugly, quickly. Consider a board-mount male XLR connector. Neutrik has a dozen choices, Switchcraft has many more, and there are other vendors. Most footprints (and panel cut-outs) are incompatible. So calling a library part XLR-M is clearly insufficient, unless you know you will choose exactly one type of this part and never consider another. What I’ve done is to rely on my parts list, Kicad’s symbol browser and its description field and call the part by its manufacturer’s part number. I am familiar enough with Neutrik’s parts to know that the NC3MAH is a board-mount right-angle male XLR connector. What about JB15LPF-JF? Well, my parts list tells me that’s an NKK momentary pushbutton switch with a green LED. Since my parts list doesn’t have every imaginable switch, this is manageable.
Variants and Families and Part Numbers and Symbols
Above I mentioned that my library has the LM317T and LM317EMP devices. Two symbols, two distinct devices … but two company part numbers? Yes, but — I use the part number variant field to distinguish between the two. Thus, LM317T has a part number A-1000-0 and LM317EMP has the part number A-1000-1. This is trivial, I admit, but there is a rule here. A variant indicates that all of the parts with the same category and part number are the same except that they vary in exactly one respect. In the case of our voltage regulators, that one variable is the package. In this manner, one might wish to define a part number for a microcontroller with 32 kB flash and its pin-compatible smaller brother with 16 kB flash. The two can be distinguished by the variant.
Now, the big one: what to do about parts such as resistors, where an entry for each individual value, package and tolerance would quickly cause the library to grow to a ridiculous size? (I should note that I worked for one employer whose library really did include one entry for each resistor value, package and tolerance that they used.) This is where the concept of a “family part number” comes in.
The idea is that the category and the part number indicate a family of parts which vary only in value. The family is represented by only one symbol. Consider the standard 0805 1% resistor. We create a symbol called R0805_1%. Its Footprint field is populated in the usual way. Its custom PN field has B-1000 entered (no variant included). The Value field is left at the default (which is the part name, in this case R0805_1%).
As the engineer places the resistors on the schematic, s/he must edit the part’s Value field appropriately. What does this mean? In my Master Parts List, for these resistors the variant part of the part number is the value. A 100Ω 0805 1% resistor is part number B-1000-100R, so the user enters 100R in the Value field. A 2.67kΩ resistor in that family is part number B-1000-2k67, and as such 2k67 is entered in the value field. And so forth.
When a BOM is exported from EESchema using the bom2csv.xslt script, the resulting CSV file will include the part number and the value for each part in the design. To get a final BOM, with orderable part numbers and manufacturer names and quantities for each part, I parse the CSV against the Master Parts List with Python script. The script “knows” that for parts in the Resistors category B, it must concatenate the part Value with the PN to get the Part Number key into the Parts List, and from there it can pull the manufacturer part number. Parts such as ICs, where the “family” concept isn’t used, have the full Part Number key already from the part’s PN field.
There are likely better ways to build the final BOM. One would be to have the Python script work directly on the schematic, rather than rely on the XSLT script to create the intermediate BOM. Another way would be for the Master Parts List to be built in a proper SQL database, which would import the Kicad CSV BOM and work on it without a Python script.