I am learning how to read schematics.
Are there any guidelines or good practice on reading schematics?
It's my understanding that schematics are read left-to-right and that is how one should follow the signal: from left-to-right. Is that correct and are there any other guidelines like this one?
I am learning how to read schematics.
Are there any rules on reading schematics ?
It's excellent that you ask this question before drawing your own schematics
It's my understanding that schematics are read left to right, and that is how one should follow the signal, from left to right, is that correct and are there any other rules like this one ?
Left to right, for all the signals that you can, is good practice. All professional schematics follow that. Many amateur ones do. It will grate when you find one of the many that don't, you just have to do more work tfel ot thgir morf gnidaer.
Often however you will get a feedback signal signal that simply has to go right to left. Try to set it apart a little from all the other wires, so you can see what's going on.
Other practices -
Those are the important ones for me. Others you can find here.
A good schematic should represent the structure of the design, while having a logical, causal flow.
Let’s talk about historical practice for a moment.
One key rule, signal flow left to right, helps with understanding causality. It’s the standard go-to for expressing signal chains. This paradigm is useful most of the time, and not just for schematics: workflow diagrams, signal processing chains and other architecture diagrams will use it.
(Aside: there’s a cultural bias at work here. If you read Arabic, Persian or Hebrew you might feel differently about left-to-right.)
Nevertheless this left-to-right paradigm is often too restrictive to adequately represent design structure. It separates signals that belong together as bundles, simply because they’re ‘input’ or ‘output’. (What about bidirectional? Power?)
The flow left-to-right rule had another rule that some companies enforced to the extreme: offpage inputs on the left, outputs on the right. Unfortunately, the extra lines needed to drag ports to the edges tended to clutter the schematic while obscuring the origin or destination.
I lived with traditional work products like this - and hated them. Over the course of my career I had conflicts with old-school designers about this, even when there was no policy about it.
At the time I started drawing my own schematics as a designer, I was lucky enough to work in chip start-ups that didn’t slavishly follow these rules. My drawings instead grouped signals together as ports, with a shared source/destination page where possible. My PhD-level co-workers were fine with it and liked it better; the technicians liked it. It was only those old draftspeople who complained.
And so it is today. Most of my designs consist of some kind of ‘hub’ (e.g., an SoC) that connects via ‘spokes’ to the various sub-blocks. Signals flow in both directions in these spokes, yet logically the signals within them group together. I rely heavily on meaningful names to show related signals in a group.
Imagine if you had to represent your design in Verilog, then document it in something like Visio (or, heaven forbid, PowerPoint.) It would look very different than a traditional left-to-right flow. It would be blocks connected together with related bundles of signals (ports). And the signals within those ports would use non-stupid signal names.
That’s how I draw my stuff. Block diagram first, sub-blocks later, with signals grouped as ports related to that hierarchy, much like one would do if coding the design in an HDL.
I take the extra time to arrange the top diagram to hint at physical placement. Layout folks really appreciated this, so did technicians debugging my stuff.
A further benefit of a structured schematic is being able to re-use pages in other projects.
(That said, hierarchical schematics are a bridge too far. Nobody likes them, except perhaps software people who appreciate the layered idea but don’t have to interact with it.)
As you read a schematic then, try to identify these relationships and apprehend the design structure, even if the designer didn’t bother.
Also, understand that power and ground are signals, too, with their own origins and destinations.
Good examples of complex, yet well-structured schematics can be found in Xilinx’s reference boards. They have a clear top diagram showing both logical and approximate physical relationships to the big FPGA in the middle.
There’s a big difference between what you should strive for in your own diagrams, vs. what you will find out there in most cases.
Unfortunately, many people - even in professional settings - draw schematics as a bunch of dashed-line boxes, with a partial circuit inside each box, and net name labels sprinkled inside said box. Each box is a sub circuit, and the net names form a netlist of interconnects between the circuits. This is enough to verify agreement between the schematic and the PCB, but is not very nice to use otherwise.
There is not much to follow there, since the graphical layer of the overall schematic and data/signal flow is lost. Such schematic diagrams miss the point of how a schematic should work as an engineering drawing: the lines aren’t there just to show connections, but also should guide the understanding.
An average schematic drawn that way doesn’t provide easy answers to even the most basic of questions. Say, you want to know where a particular voltage rail is used. You can only hope to find all the net names of that rail and not miss any. There’s no graphical content to guide you. Same goes for most nets that span between sub-circuits.
The “following” of a signal between small circuits blocks on modern schematic thus amounts to find-a-word game among the net labels. Often the “circuit block” is just one chip, eg. MCU, and you have to build up the schematic diagram in your mind or in a notebook - the work of actually making a readable diagram is left as an exercise for the reader, so to speak.
Now, that’s how it often is when there’s no continuity of engineering culture where the schematics originated. Download a random evaluation board schematic from most any vendor out there and most of those “schematics” are indeed graphical find-a-words. Same goes for a lot of open hardware projects that are not purely analog.
If you’re lucky to work on circuits drawn well - where the graphical language is used to convey the function to the full extent - you’ll not only be able follow the signals. You should expect the schematic to be organized in a logical fashion that exposes the function of the circuit. That’s the ideal case.
Now, it bears saying: not all “old school” discrete component schematics are drawn well. Not at all. There are plenty of schematics that use lines everywhere, but are not structured to expose the big picture - they hamper visual following of the signals. Such schematics ignore sound principles of visual design: grouping, the use of white space, reactive scaling of circuit elements vs. sub circuit organization, and so on.
In closing: the schematics you read will be very often not how you should draw your own schematics. Diagrams of test and measurement equipment from the era when component level repair was still practiced usually set a good example to follow. But not always. And there are plenty of companies beyond HP and Tektronix that made beautiful diagrams of course.
Well-crafted schematics of analog electronics were works of art. Often annotated with the signals you would expect to see on test points, lots of notes and so on. Probably created on drafting boards by professional draftspersons rather than harried engineers. Ideally they'd be created showing signals travelling left-to-right and with more positive voltage rails on top. Of course they might have to snake around to use the schematic sheet efficiently and you often have multiple inputs and multiple outputs with different relationships, so those are only rough guidelines.
Modern EDA tools and chips with hundreds of pins (or more) have led to multi-page schematics that are quite difficult to follow (for some purposes anyway) without viewer software. The same part may be broken into several symbols to keep the complexity reasonable, and you may be better off using a search function rather than trying to find out all the places a given net label shows up in a schematic. Ideally they'll be broken up functionally, perhaps a couple sheets devoted to an MCU, a couple more for the external memories, another for the Ethernet interface etc. But something like an I2C bus may go to several ICs, an off-board connector, test points and so on. So actually following the signal may be a bit of a quest when there are net labels and off-page connectors and that sort of thing used rather than old-school lines on a page.
