EDA libraries: the transition from standalone to database libraries
We share this blog because we are currently in the transition of moving from standalone libraries to database libraries for our EDA (Electronic Design Automation) tool Altium. As you may know we, and also the majority of design houses, are still using standalone libraries. We want to make this transition because we are growing and running against some challenges.
How EDA libraries worked until now
Libraries are containers to store components in. Components may consist of schematic symbols, PCB footprints (shapes), simulation models and a lot of other parameters, like MPN (Manufacturer Part Number), manufacturer, value, etc. Some EDA tools like Eagle do have one single library for symbols and footprints, while other tools do have separated libraries for symbols and footprints. Other tools like Altium do have both options.
You may have one library to store all your components in. However, this may become a big file which is difficult to maintain over some time. So, you better split them up into categories like capacitors, resistors, IC’s, diodes, transistors, etc. Or maybe you are using a dedicated library for every project, whatever works best for you.
The challenges with standalone libraries are:
- To keep a consistent and clean structured library so that components are easy to find.
- To maintain your libraries: keep them up-to-date and uniform.
- To make sure that every engineer works with the same up-to-date library.
- To prevent that every engineer uses his own variant of a corporate standard.
- Adding components of the same series can be time and library space consuming. Like adding a whole capacitor range with all those values (1nF, 2n2F, 4n7F, 10nF etc) means multiple copies of the same part.
How EDA libraries can also work
All the above challenges are addressed when using database structured libraries.
When using database libraries, you can keep them very clean. Apart from an unique ID you do not need to enter any parameters to the components. For example: when creating a library for capacitors you only need a few symbols like a normal capacitor, polarized capacitor and maybe a variable capacitor. That’s all!
Unfortunately, for the footprints you will need a lot more. Like all the SMD shapes such as 0201, 0402, 0603, 0805, 1206 and a bunch of through hole shapes.
The topology: Access, SQL and Altium
We choose to use Microsoft SQL server as our back-end. Currently our SQL server is also our back-end for our ERP system. This will gain the possibility to gather real time status information of our stocked components in Altium, running nightly jobs to update information and performing back-ups. To maintain our Altium SQL database, we wrote a front-end in Access which will directly talk to SQL and not to Altium. So Altium does not retrieve component information from Access but directly from our SQL server. This will address the issue that you need 64bit Office for Altium version 18 and 32bit version for Altium 17. Later on we will port the front-end into our corporate, web browser based Infinity system. But for now, Access is the tool to use when adding new components or mutating data.
How to make a database library
We split the components into 13 types (capacitor, resistor, IC, etc). Every type is having a dedicated database library attached to it. Next, we categorized every type into a subtype. For a capacitor: Ceramic, Aluminium, Tantalum, etc. Then we added common and specific parameters for every type. In Altium and in the Access front-end tool you only see the type specific parameter for the selected type. This will generate a clean view of all the parameters.
The baseline has been setup. It is now time to test and use the database in practise.
Of course there are some tweaks to do, but the first steps have been made and are looking very promising.