Light and heavy symbols

tag:blogger.com,1999:blog-31006871.post-79242355261107534572008-10-20T09:09:00.002+02:002008-10-20T09:30:05.397+02:00Light and heavy symbolsThis post is aimed at electronic engineers working with electronic design automation (EDA) packages. 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 <a href="http://blog.engineersimplicity.com/2006/08/you-do-what.html">creating solutions to problems</a>, 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. <table><tbody><tr valign="top"><td>component</td><td>:</td><td>an actual physical part.</td></tr><tr valign="top"><td>symbol</td><td>:</td><td>a diagram depicting a component which is placed in a schematic drawing.</td></tr><tr valign="top"><td>footprint</td><td>:</td><td>the physical layout of a component on a PCB.</td></tr></tbody></table> 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: <ul><li>Data duplication,</li><li>Errors requires changes to numerous symbols, </li><li>Require a librarian to maintain symbol library sanity,</li><li>Single source of information.</li></ul>Light symbols: <ul><li>No data duplication,</li><li>Errors can be fixed at schematic level, or only affect a single symbol,</li><li>Allows multiple data sources for component information,</li><li>Requires addition of attributes at schematic level.</li></ul>If you remember that <a href="http://blog.engineersimplicity.com/2008/10/information-duplication-is-enemy-of.html">I am against information duplication</a>, then you should have guessed that I am in favour of light symbols. The "light" and "heavy" nomenclature arose out of discussions on the <a href="http://geda.seul.org/">gEDA</a> mailing list. The <a href="http://geda.seul.org/wiki/geda:faq-gschem#what_s_this_business_about_heavy_vs._light_symbols">gEDA wiki has a brief summary</a>, and the two threads which I think are the most relevant are "<a href="http://archives.seul.org/geda/user/Jun-2005/msg00001.html">Light vs. Heavy gschem symbols?</a>" and "<a href="http://archives.seul.org/geda/user/Dec-2007/msg00146.html">Heavy symbols and such</a>."<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/31006871-7924235526110753457?l=blog.engineersimplicity.com'/></div>Duncan Drennanhttp://www.blogger.com/profile/18356141566912975917noreply@blogger.com4