Why Library Conformity Matters

Library components in the PCB design domain are problematic because there is no standardization between EDA software suites. If standards existed, component manufacturers would simply provide the symbol and footprint graphics along with the component definition. The STEP (Standard for the Exchange of Product Data) format is a perfect example of this universal definition. Because STEP is universally accepted, finding the 3D representations of components is far easier than the electrical symbols or footprints for a given EDA tool.

As a result, this lack of standardization forces designers to do things on the fly. They will do the minimum necessary to make or extract components to keep the project moving forward. They may copy from other projects or find the component from a third-party site.

Most companies do not enforce library conformity among engineers and designers. Either they do not know it is an issue, or they know it is an issue but do not wish to tackle it because they see the enormity of the problem.

This can go on for some time, for years; however, the consequence of the on-the-fly approach does catch up in several ways. The lack of component centralization creates issues that propagate throughout the company. For example, in an environment with no centralized library, it is not uncommon for a designer to create a component that a colleague has already made. As a result, two company part numbers for the same component exist. These mistakes ultimately propagate to the assembly floor. Thus, simple library issues like this can result in a company losing its economies of scale and revenue.

Another issue is the lack of consistency between the design projects, resulting in some projects moving forward without apparent issues and others constantly being respun. Most importantly and especially given the supply chain issues that the world is currently experiencing, there is no clean synchronization between the designers and the purchasers.

This is a massive undertaking when there is a revelation in the company that the libraries need to be centralized. Since there is no guideline or most designers fail to follow it, gathering the components from personal libraries will not make an extensive centralized library. It's just a compilation of disparate components. There needs to be decisions and agreements about the library structure (a.k.a., which product to use to store the components), the configuration of its revision and life cycle flows, and the declaration of component categories and the parameters for each component category. In addition, symbol and footprint graphics must be reviewed and validated for standardization. None of these can be done in a vacuum. They need to be discussed by a team and consensus achieved.

This library's clean-up does not end when the components are cleaned up and migrated. New components are still going to be required. Design team members can quickly turn the library into a hash if they are not cooperative. They can introduce duplicate symbols, footprints, and components that do not follow the company standard. Using these rogue components in projects in revision-based library structures (like Altium 365 and Concord Pro) makes it more challenging to correct the issues. It requires a clean-up of the library and the project. The longer it remains in error, the harder it will be to fix. Remember, the revision control system is there to maintain a history. A change does not stomp on a file; instead, it creates a new file. Thus, constant corrections only bloat the underlying library database.

Worse are those designers who continue to buck the central library and create components independently. This creates what we call the "contractor's loop." This makes it more challenging to resync the design to the libraries. The library components must be extracted from the project, introduced into the library, and then resynced. The symbols and footprints will likely not follow the component standard, resulting in symbols and footprints being shifted or rotated upon resync in the project. This will require a careful review of schematics and the layout to ensure that nothing got disconnected or inadvertently rewired.

Some designers will argue that a centralized library will slow them down. However, the reality is that the environment in which they work is already slowing them down, and they are working harder to overcome environmental inefficiencies. Most of this has to do with the libraries.

Some designers will argue that centralized libraries restrict "creative license," but such a concept should be applied to the electrical design, not the libraries. Consider this analogy. Think of the library as being Lego pieces. The idea is that by having these predefined pieces, you can create whatever comes to your imagination within the limits of the physical properties of each Lego piece. The idea of cutting or snapping a Lego is genuinely the last resort and, to some people, a sacrilege! Libraries must be treated like Lego pieces and designed to fit within the company guidelines. Keep creative license within the bounds of the electrical design and physical layout.

In summary, conformity matters when it comes to component libraries. The time not taken when first creating the component will be the additional time and money necessary to clean up components (and projects) in the future. The old saying goes, "An ounce of prevention is worth a pound of cure."

Tell me more
Tell me more