In summer 2019 I have been invited to join the KiCad librarians team. As a librarian my job is to review additions and enhancements of the KiCad-library. Those include footprints and symbols in their respective repository.
All submissions should adhere to the KiCad Library Convention (KLC) which is a set of guidelines to follow when contributing to the library.
Unfortunately there is no on-boarding for new maintainers. And no ‘real’ process for checking contributions. It is up to the reviewer to learn all of that themselves. Thus, I decided to write down a small list of the items I usually check when looking at submission. This list is not comprehensive, so only take it as a starting point!
- Could the new symbol be an alias to an existing one
- If its an alias, some of the checks can be skipped since the base part is already in the library. Only the
dcmfile which contains the keywords and description need detailed checking. - A quick check for the base part should be done anyway. This is a great opportunity to find bugs. If possible also fix cosmetic issues if it does not break compatibility.
- If its an alias, some of the checks can be skipped since the base part is already in the library. Only the
- Are there symbols with similar function already in the library? If yes, does the new symbol conform to the style set by the existing ones?
- Sometimes the existing style does not conform to KLC. Then some research should be done to figure out why that is the case. Some symbols are rather old and were made without proper checks
- Perhaps the existing symbols needs rework as well. If its just a small amount of work and a non breaking change the contributor can be asked to take care of that as well.
- Is the new submission in the correct library section? There are some corner cases or even devices that by no means fit into an existing library. Then a new library can be started.
- Is the new symbol a generic or a fully specified symbol
- Should there be additional aliases? For example fixed voltage regulators usually come in with different voltage options. It is good to have one alias for each output voltage.
- Check the Symbol name
- Is it consistent with other similar symbols?
- Is the naming according to KLC scheme? For some classes of devices there are explicit rules on how they should be named. For example connectors should include the inserting direction (horizontal, vertical).
- Figure out if the part name includes no functional parts. They must be replaced by wildcards. That often includes Temperature or ROHS Variants coded into the package suffix.
- Pins
- Verify names and pin-numbering against the datasheet
- Are the pin electrical types helpful for the DRC? Most datasheets give information about pin types. Look for open-collector pins, special power pins, …
- In most cases the GND pins can be stacked. Sometimes this also applies to power pins or even I/O.
- If the package has an exposed pad or other features (shield, mechanical mounting), is that properly represented in the symbol
- NC pins should be on the outline of the symbol body.
- Pin layout (which pins go on which side of the symbol)
- Again, check for consistency with similar symbols
- Perhaps ask the contributor to provide an example how the symbol would be used in a schematic.
- Perhaps reshuffle pins (a popular example are
XINandXOUTfor a crystal. Its useful to space them by 200mil soCrystal_Smallfits between the pins) - Correct ordering (e.g. numbered GPIOs)
- For multiple units: does the split make sense?
- Metadata
- Matches the Datasheet, is consistent with other parts in the lib
- Package name at the end of description for standard packages
- Keywords exist and make sense, perhaps additional keywords required
- Datasheet link exists, page-number anchor if applicable
- Footprint
- Exactly matches datasheet (check drawing)
- Datasheet matches kicad-footprint pin numbering (there are vendors that don’t follow JEDEC)
- Filter matches, pin-count not included (unless required)
Perhaps I will make a similar list for footprints in the future.