As an electronic engineer you have probably been through it. It all starts simply and clearly. You need to draw a schematic; so you make some symbols, attach some attributes to them and get going. Then you draw some footprints for the PCB layout and make sure the correct footprint names are attached to the components you have created. The boards go the PCB manufacturer and you use a simple spreadsheet to manage the bill of materials (BOM). Everything goes nice and smoothly – you are happy.
Then another project comes along – a bigger one with more engineers working on it. You carry on like you have before, explaining to people how to create new components and footprints and how to make sure the part numbers are correct. It all seems to be going well. The PCBs and components arrive, but something is not quite right. One of the components (an expensive one!) is the wrong part, and another component does not fit onto the PCB footprint correctly (even though there is another component with the same footprint that does fit correctly). What went wrong?
Eventually with more projects and more people managing the component library becomes a full time job for someone, and getting a new component approved is a lengthy process for engineers. Let's not even talk about managing the now massive stock and BOM spreadsheet which keeps you awake at night. The quick process you started with has become a slow moving, time consuming beast. We need to find a way to kill that beast so that engineers can spend more time creating solutions to problems, and less time on administration.
There are two ways to handles components. We can either have "heavy" symbols, or "light" symbols. First a few definitions so that we are all talking the same language.
| component | : | an actual physical part. |
| symbol | : | a diagram depicting a component which is placed in a schematic drawing. |
| footprint | : | the physical layout of a component on a PCB. |
A heavy symbol has all of its attributes, such as part name, value, voltage, tolerance, footprint, ordering number, etc. specified in the symbol library. A light symbol has no attributes specified in the library and all attributes are added at a schematic level.
There are some obvious flaws with each approach. A heavy symbol library will quickly grow in size – just think about having a symbol defined for each different opamp or resistor that is used. The graphical representation of an opamp is generic to a number of different parts, but now duplicates are created for each component. If a fault does creep into the library it can result in a number of different symbols needing to be fixed.
With a light symbol library all the attributes are added to the schematic. Maintaining the symbols is easy (because there are fewer), but ensuring that the correct attribute information is added can lead to errors (each time data is manually copied or entered there is the potential for an error).
There are also some obvious advantages. A heavy symbol immediately makes a lot of information available in the schematic which can be passed on to other tools, such as the footprint to the PCB layout package, or the part number to the BOM. A light symbol allows for information to be drawn from multiple sources, and the schematic can be updated without having to propagate the changes back into the library.
Here is a brief summary of the feature of each type of symbol.
Heavy symbols:
- Data duplication,
- Errors requires changes to numerous symbols,
- Require a librarian to maintain symbol library sanity,
- Single source of information.
- No data duplication,
- Errors can be fixed at schematic level, or only affect a single symbol,
- Allows multiple data sources for component information,
- Requires addition of attributes at schematic level.
The "light" and "heavy" nomenclature arose out of discussions on the gEDA mailing list. The gEDA wiki has a brief summary, and the two threads which I think are the most relevant are "Light vs. Heavy gschem symbols?" and "Heavy symbols and such."
Hi Duncan,
ReplyDeleteEven though I understand the rigors of maintaining a heavy symbol library, I am in favor of it. The main reason is longevity of projects. I'd like to think that if I design a product that it will still be alive and well 10 years later. If a young engineer comes in and looks at my schematic and sees that I need an op amp and thinks "oh, well I'm sure a LM741 will work fine here. It's just an op amp, right?" In fact, the node the op amp is on was very sensitive and required pA of bias current and mV of offset voltage. Not only that, the young engineer also gets the part in house and realizes they have the wrong part size AND pin layout. So while I understand your argument for speed and simplicity of maintaining a library, I think designing for long term projects might convince you otherwise. Good post and one I enjoy talking about!
Chris
Hi Chris,
ReplyDeleteAll the necessary information is still stored in your schematic, just not in your library. The schematic has detailed part info and so on, but the library does not (attributes are added to the schematic after placing the symbol from the library).
The symbol library just has an opamp symbol (with the correct pin-out), then the part number (and any other attributes) are added to the schematic. The schematic persists over time, and the new engineer should still know what is going on.
A ha! Good point Duncan, one I had not thought of. So if you have people who are meticulous when they link up the part name (I'm assuming one specific enough to give all the pinout information and such), then you'll be in good shape. Excellent point!
ReplyDelete~Chris
I agree that symbols should be light. Attributes for each component should be stored in a database, along with a reference to a symbol. If you draw a schematic for a PCB design you should preferably not place symbols (really!) but a component from the database. The correct symbol with attributes would then be in the design with just one action.
ReplyDeleteFrom my experience with Mentor-DxDatabook and Cadence-Capture-CIS as both designer and component-library/database maintainer I believe this is the way to go for any design team that involves more than one person or more than one design. The advantages are numerous.
For gEDA both gschem and gattrib should be database aware for this to work properly. This is an absolute requirement for any schematic capture program to function in a company that does multiple designs.