Centralizing Component Libraries Print E-mail
Written by Manny Marcano   
Monday, 09 May 2011 21:42

Team design mandates a common, enforceable parts management approach.

As a reseller of electronic design automation tools and solutions, I’ve spent a lot of time with companies that design electronic products. One common trouble spot is how engineers manage component libraries. I am constantly amazed at the number of engineering teams that continue to design from separate libraries of components on each engineer’s workstation.

The concept of a component information system (CIS) has been around since the 1990s, and most major EDA vendors offer one form or another. The premise is simple: Keep all the components organized in a centralized library linked to their CAD tool of choice so that a group of engineers can reduce time spent researching, manually entering, and managing component data. The bigger benefit, though, is that once a team has a good set of component data, their designs get populated with complete and accurate information that follows company standards.

Let’s look at a typical approach of a team that’s not using a CIS. An engineer, let’s call him “Joe,” has his favorite schematic tool installed on his PC, and with it came a set of components, consisting mainly of generic part numbers and symbols. Also present is a set of components Joe created for previous designs, and these typically have the minimum information needed at the time.

During the design process, the designer manually searches the set of libraries, finding components to suit their needs. To do this, Joe the engineer has most likely developed a specific, and often unique, naming system to identify characteristics of the components when searching this library; e.g., Cap_01uF_FP_CC1206_5prct_50v_x7r_kemet_C1206C104M5VACTU. This can be effective for the solo engineer, but typically does not scale well to larger teams that must decipher the naming scheme. Consider the difficulty when using a coworker’s library, or taking over someone else’s work, and the naming conventions don’t match.

As Joe progresses, he finds he needs a new component for the library. After some research, usually visiting distributor and vendor websites, he finds the component, draws a symbol, copies needed attributes from the datasheet, creates a unique name, adds the part to the library, and finally adds the new part to his design.

As Joe is adding new parts to his library, so too are the other individuals on the team – sometimes collaborating on components and libraries, but often simply focused on their own problems. For a few components, this is not a big deal, but the problem grows with time and team size. Wouldn’t it be nice if Joe could see not only his library, but those his coworkers have created? Then he wouldn’t spend the time to create a component someone else – maybe on a different continent – has already created. Joe would simply use the component already created by his coworker. The savings on a small component, like a resistor, are certainly negligible, but as the size and complexity of the components increase, and as the number of new components increases, so too does the time savings.
What about consistency? It’s easy to design similar, but not identical, components into different parts of the design. They might even be the same package, but from different manufacturers. Many companies implement processes for approved vendors and approved components to help solve this problem. My observations tell me that a CIS makes these policies easier to follow – and enforce. If the desired component is already in the database and easy to find, there’s much less chance Joe will create a component that isn’t needed.

With one of the components in the design? Simple – Joe fixes his library and the problem is solved, right? Maybe. What about the other designs where this part may have been used? What about the other engineer who designed-in this same device separately with the same problem and hasn’t been notified of the part change? With separate libraries, there is no effective way to communicate a component change to the other designs and designers using that particular device. Again, a CIS provides a central location for every part and all part knowledge. Not only does this simplify component changes, but it packages your entire component IP into a single, well defined system. As components and component information are added, the component IP evolves into a valuable and reusable asset.

What if Joe adds Ray the engineer to the design team? It’s a simple matter to connect Ray’s schematic tool to the CIS so he has all of the team’s (or company’s) part IP at his fingertips. He can explore, query, and filter according to component specification criteria, and zero-in on a specific physical component, because the CIS is implemented as a single, intelligent database with logical and intelligent search capabilities. And when Ray places that component in his design, all that intelligence comes with it. It’s very efficient, and it helps him follow the team’s standards.

The culmination of any project – at least for the purposes of this discussion – is the bill of materials. Since all the components of the design come from the CIS, it’s a simple process to verify that all components have all the required fields. If the review process finds problems with individual components, the proper place to fix the problem is in the CIS so that future BoMs and designs make use of this corrected information.

Manny Marcano is president and CEO of EMA Design Automation (ema-eda.com); This e-mail address is being protected from spambots. You need JavaScript enabled to view it . His column runs regularly.

Last Updated on Monday, 09 May 2011 22:32




CB Login



English French German Italian Portuguese Russian Spanish

Printed Circuit Design & Fab Magazine on Facebook