Nice Circuit, Ugly Schematic

The wiring schematic is a standard part of a design's "reveal." When it is done with the right engineering esthetic, it reflects well on the design and the designer.

Jim Williams, the late and sorely missed analog-circuit expert, used to say that a good schematic diagram was itself a work of art, which in turn captured and revealed the intricacies and subtleties of a circuit design.

He was right, of course, and I realized this the other day when I was looking at the schematic of a basic alarm controller from about 30 years ago (no need to explain here why I was doing this). Due to the application, this design was largely analog and basic digital ICs, with lots of I/O points and just a small microcontroller function.

What struck me about this schematic was how poorly drawn it was: Signal lines and power rails crossed themselves and each other like a bowl of spaghetti. As far as I could tell, it was technically correct, but both visually confusing and hard to use for any sort of troubleshooting.

Why was it so poorly done? I have no idea: Perhaps someone with no EE background drew it; perhaps the engineer who did it was in a rush and didn’t care; or perhaps it was adapted from a crude hand-drawn sketch. (I won’t blame this on a CAD/EDA program, since it did not at all have the look of being computer-sourced.)

This circuit, from a 1992 EDN Design Idea, measures alternating current or voltage and transmits the results on a 4- to 20-mA current loop.

One of the reasons I prefer to look at older schematics is that they are mostly analog and so have little or no processing core. Thus, single-handedly or in conjunction with a block diagram, they can reveal most the circuit’s functions and operation. In these schematics, the signal flows like a stream from left to right beginning at the input(s), then gets caught in various eddies and pools of sub-circuits for filtering, calibration, compensation, thresholds, oscillation, mixing, modulation/demodulation, and other functions before it emerges at the right side, going into the open world as an output signal.

In contrast, in designs that are heavily centered on their processor/software, it’s hard to establish any signal-processing flow. Much of the real “action” (functionality) takes place in the mysterious CPU section -- which is largely a magical black box, unless you study the code.

A well-drawn schematic not only gives you the facts of the circuit, it also tells the story of the circuit. The same guideline applies to software documentation, too, of course: A good code listing not only gives you the instructions to be executed, but tells what the intention of the code is at various blocks and junctions.

Hardware and software engineers who don’t provide meaningful, well-done documentation are not only hurting themselves and the "next guy" who has to deal with the design -- and there usually is a next guy -- but they are also making themselves look bad. After all, you wouldn’t be impressed by an article or technical paper that was full of misspellings, fractured sentences, and semi-coherent ramblings.

HI Bill. I loved the old transistor radio schematic (being British by extraction I still prefer Circuit Diagram even though it takes longer to say and write). Obviously from a coil manufacturer trying to sell his wares (note the list of trnasistor types you can use at the bottom!)

I think the nice thing about diagrams like this is that you have the power rails running along the top and the bottom and it's obvious what they are. Looking at the EDN one, one IC is supplying the other two ICs but It takes a bit of examination to find this.

The worst as you say are MCU diagrams where the tendency seems to be to put ICs in isolation with a funny shaped box on each pin with a cryptic signal name in each. Somewhere on the rest of the diagram is another box, going into another IC, with the same signal name. Look, Ma, no wires! :-) But to be fair some of those circuits would be very difficult to draw without looking like spaghetti.

I recently had to trace the circuit of a drill charger from its PCB. I ended up with a real rats nest on a piece of paper. I managed to draw it properly with only 2 crossovers. It made it obvious how the circuit worked. and I found the tidying-up process very satisfying.

Schematic styles are always an interesting thing to observe. Do you try and fit it all on 1 page or spread it among several pages where signal flow is not as easy to follow? Do you keep it architecturally flat or use the logical, but hard to follow, hierarchical design? Do you place critical components like decoupling capacitors near their respective integrated circuits, or show them all in a common area connected to supply rail? Do you make it clean looking by using wire stubs with node names for virtual connections, or make it easier to follow by showing complete lines of connectivity? Do you use descriptive net names to aid in understanding, communicating, and documenting degugging efforts? Do you include net name locators for on-sheet of off-sheet connections, or leave the user to search the schemtic to find them? How do you deal with multiple grounds?

One general observation I have made over the years is the folks responsible for implementing and debugging systems have a drastically different approach from folks whose primary design responsibility is ASICs or FPGAs.