Types of Library Management

Types of Library Management

The following categories are listed least-to-most sophisticated, but most businesses pick and choose a minimal mix of all of these.

In-file design Libraries

Most organizations start with an in-file design library. It’s often fully integrated into the schematic, PCB, and ECAD project files. This works for most smaller organizations as the overhead of managing a few PCBs per year is enough for a single engineer.

Ad hoc library: symbol and footprint files

Separating the symbol and footprint information from the schematic and PCB files allows them to change independently of the PCB design. Without version control, centralization and a more formal process, these libraries often have the same problems as no libraries. Designers often go rogue and make their own libraries, defeating the purpose of having external library files.

Version controlled library files

Version controlling external library files is such an easy and productive process to adopt, that it should be one of the first operations when starting a PCBA design. The design delays and production issues with component errors is worth the ROI on starting a minimal version controlled component library.

Version control allows you to do small daily steps to incrementally improve your libraries.

Here is an example workflow where a design engineer needs a new component, like an LVDS clock driver.

Version controlled library best practices

• Separate files for component categories

  • They all have their own complexities

  • Smaller changes more often

  • Separate resistors from capacitors

  • Semiconductors by type

    • Microcontroller/microprocessor/FPGA/etc

    • RAM

    • Logic

    • Power

    • RF

  • Hardware by type

    • Connectors

    • Cables

    • Externals (i.e. SD card, battery, antenna)

    • Fasteners

  • Operations

    • Barcodes (2D, Matrix)

    • Stickers

    • Laser markings

Challenges of simple version controlled libraries

Component ordering attributes are often still embedded in the symbol files at this point. They have to be manually exported and then massaged into a format manufacturers can use. Even if the information is in separate “integrated library” files or database, there is often a manual and error-prone process involved.

CI controlled libraries

With the addition of Continuous Improvement (CI) Action Runners, you are able to bolt-on an automated component librarian:

• Never sleeps, never sick, always sharp, never gets distracted

• Follows process exactly

• Fetches component data

  • Extended BOM + COGS

    • Single and multiple quantity scenarios

  • Availability and lead time

    • Generate fast/slow PCB assembly turnaround build plans

  • Automatic component alerts

    • Price changes

    • Lifecyle changes (End of life, NRFND)

    • Low quantity

    • Long lead-time

• Generates where-used and usage data

• Syncs with PLM and ERP systems

  • AllSpice.io → PLM/ERP

  • PLM/ERP → AllSpice.io

  • AllSpice.io ←→ PLM/ERP

• Syncs with common databases

  • Relational: SQL, MySQL, MariaDB, PostGress, SQL Lite

  • Non-relational: NoSQL, MongoDB

  • GraphDB

• Knows every programming language and framework

  • Works with existing tech stack

    • Python/Mojo/Django

    • C/Rust

    • Javascript/Ruby

    • Anything supported by Ubuntu 2024 LTS

Here are some CI workflow diagrams

CI Actions

CI is easy to understand. It’s a separate server that spins up a fresh software container (like Docker) and then runs any program in any programming language that you want.

• Run Checks

• Connect to external APIs to write or fetch data

• Generates files (BOM, Drill, XY, FAB)

• Generates documentation (compliance, utility, history)

To learn more, visit our Actions CI/CD page.