CC Blog Quick Bits Resources

Drawing Schematics

Written by Andrew Levido

This is a potentially controversial topic. Schematic drawing style is a very personal matter and varies considerably from organization to organization even and from one part of the world to another. So why am I offering my opinion in this sensitive area? Because I am seeing more and more schematics that are more difficult to read than they need to be.

I think this is because of the proliferation of EDA tools and on-line schematic symbol libraries. I am not advocating the return of the drafting table, but I am suggesting we put a bit more thought into the drafting of our schematics.

I believe strongly that the primary purpose of a schematic should be to make your design understandable to humans. Your EDA tool on the other hand, sees a schematic purely as a means to create a netlist and a bill of materials. If we exert creative control over our schematics and follow a few simple conventions, we can do a lot to improve the readability of our diagrams.

Unfortunately, there is no single standard for the drawing of component symbols, and the standards that do exist (IEC 60617, ANSI Y32.2-1975, IEEE Std 91/91a) are outdated and contradictory in places. Many organizations maintain their own standards or conventions which may or may not be aligned with these. My suggestion is you choose your standard (even if it is a hybrid) and stick to it religiously. This may mean you have to draw your own symbols. Don’t just use whatever symbol you happen to find attached to a component model on-line.

For example, I use an IEC/IEEE style for most parts. This is just an accident of geography as I am based in Australia where our standards are traditionally lean more toward the European equivalents. Figure 1 shows a few examples of IEC and ANSI symbols for various parts simple parts. sees a schematic purely as a means to create a Bill of Materials and a netlist.

Figure 1

I also use the IEEE style for logic gates (Figure 2). ] as the schematic explicitly describes the function of the device. The 74HC138 address decoder shown here is a great example. Once you learn the dependencies (The G and EN for gate and enable in this example) you can easily see exactly what the device does. The ANSI approach treats logic functions as plain rectangles, and you have to look up (or guess) the rest.

Figure 2

Lest you think I am a purist; I see no reason why one could not mix and match from various standards. The key is to be consistent. Don’t use a mix of ANSI and IEC diodes or ANSI and IEEE logic gates in the one schematic.

The layout  is probably more important than the symbols. Putting some time and thought into this will pay off in terms of readability and aesthetics. Here are a few guidelines I try to follow:

  • Make the circuit function clear. Keep each functional group of components together and if there is a conventional way to lay it out, use it. For example, an inverting op amp gain stage, or a push-pull output stage should look like the ones in the textbooks. Use plenty of space between each functional block to visually separate each one.
  • Pick a grid and stick to it. Align components and wires vertically and horizontally. Allow a little space around components – don’t put junctions too close to the component. Make sure your symbols are all scaled similarly and suit your grid.
  • Keep the main signal flow from left to right and/or top to bottom where possible. Use lines to connect signals on the same page (with the exception of power and ground) unless it would unnecessarily clutter the diagram. Adhere to conventions like positive power rails on top and negative power rails on the bottom unless there is a good reason to deviate.
  • Sometimes it is clearer not to connect signals on the one page and to use net labels to indicate connectivity. You also need to do this for off-sheet connections. Make sure it is as easy as possible to find where these connections go. Some people use sheet and grid references for this, but you can also provide guidance using intelligent net names and having well-labelled functional blocks.
  • Make use of multi-part components. Each gate, op amp etc. in a multi-part package should be a separate part. I also separate the power supply of gates, op amps, analog switches, and the like into a separate part to keep the power supply and decoupling out of the way of the main signal flow.

You can also split devices with many pins, such as microcontrollers and FPGAs, into several parts rather than have one giant device with 200 plus pins and a plethora of net labels. This also lets you keep pins on the sides of the component symbol and not on the top and bottom which improves readability.

  • Wires should only ever cross at right angles. A joining dot should have only three wires connected to it. This makes connections or crossings unambiguous. Don’t use “jumps” to indicate crossing conductors.
  • Use plenty of text and labels to help others (and future you) to understand what important circuit blocks do and what critical signals to expect.

There is obviously no one right way to do this and I don’t follow these rules slavishly if there is a good reason to deviate. The aim of the exercise it to produce a schematic that is human-friendly and that clearly conveys the operation of the circuit to someone not familiar with it. I think the keys are clarity, consistency, and comprehensibility. Don’t let your EDA tool, or its symbol library designers dictate how your schematics look.

“Electronic Symbol.” In Wikipedia, March 8, 2023.

“IEEE Standard and American National Standard for Electrical and Electronics Diagrams (Including Reference Designation Class Designation Letters).” IEEE 315-1971 (ANSI Y32.2-1970), November 1971, 1–92.

“Overview of IEEE Standard 91-1984.” Accessed September 12, 2023.

Keep up-to-date with our FREE Weekly Newsletter!

Don't miss out on upcoming issues of Circuit Cellar.

Note: We’ve made the Dec 2022 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.

Sponsor this Article
+ posts

Andrew Levido ( earned a bachelor’s degree in Electrical Engineering in Sydney, Australia, in 1986. He worked for several years in R&D for power electronics and telecommunication companies before moving into management roles. Andrew has maintained a hands-on interest in electronics, particularly embedded systems, power electronics, and control theory in his free time. Over the years he has written a number of articles for various electronics publications and occasionally provides consulting services as time allows.

Supporting Companies

Upcoming Events

Copyright © KCK Media Corp.
All Rights Reserved

Copyright © 2024 KCK Media Corp.

Drawing Schematics

by Andrew Levido time to read: 4 min