Monday, October 20, 2008
Light and heavy symbols
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."
4 comments :
If you are leaving a comment with your Name and URL then make sure you put http:// in front of your URL for a correct link. You can use some HTML tags such as <a>, <b> and <i> in your comment. Thanks for your message - I appreciate it :)
Note: only a member of this blog may post a comment.
Search This Blog
Subscribe
Tags
About this blog
I'm Duncan Drennan and this blog is about spreading ideas regarding engineering, our environment and creating a better world. You can also follow me on Google Reader.
About Engineer Simplicity
Engineer Simplicity specialises in the design and development of electronic products.
Copyright Notice
Popular Posts
-
We are in the middle of an energy crisis and each of us need to make some dramatic changes to ensure that we have electricity, and that the ...
-
The short version (my "elevator pitch"): Compact fluorescent lamps (CFLs) use about a fifth of the energy of a normal (incandescen...
-
As engineers we spend a lot of time solving problems. A customer has a problem and it needs to be fixed. The electronic boards you have just...
-
There are a lot of steps to turn an idea into a product. Each step requires care and attention to ensure that the best product is created. B...
-
So here we are, the first blog post...well, really, here I am. My name is Duncan Drennan and this is my blog on business, design, electronic...
-
This post forms a part of the SA Blook . So what is our reality? South Africa has an unemployment rate of about 23%, a skills shortage crisi...
-
eWaste is a particularly difficult issue to deal with as it contains many different materials and lots of extremely hazardous substances. I...
-
Electronic design automation tools like OrCAD , PADS and Altium Designer are part of an electronic engineer's day–to–day life. We need...
-
With 48 post over nearly three years, I am certainly not a prolific blog writer. My goal has never been to write a lot, but to rather explor...
-
I think that it is worth trying to understand some of the reasons we are heading towards a food crisis . The result of all of this deregulat...
© The Art of Engineering 2013 . Powered by Bootstrap , Blogger templates and RWD Testing Tool
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.