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.
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.
"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"
One of the things I like about Altium Designer is the 'Harness' device. Similar to a bus, but allows a free-form mix of signals, including busses and other harnesses, to bu grouped together as a single line.
These days my typical circuit has a top level with a bunch of subsheets connected by harnesses with suitable names. The CPU subsheet has harnesses with the IO conditioning subsheets, keypad subsheet, display subsheet, etc.
Of course the CPU sheet itself still has many labelled wire stubs, but at least I can collect many nets directly into harmesses, and can often position the others so the connections are not too hard to find. I thought to add some screen-shots, but anything useful is a bit big.
They have to look good, for heaven's sake, like any other art form. In the tube days, the tubes were often lined up on top, and all the passive components feeding them underneath. In the early transistor days, I noticed the same drawing style. But now, and I think for good reason, the active components are not typically separated.
There's nothing like a well executed, complementary symmetry analog circuit diagram, NPN on top, PNP on bottom, IMO. I like the power supply bypass capacitors to be shown close to the component they are bypassing for. And yes, chips tend to not have their inner workings show, because aside from the simplest of chips, that would be practically impossible.
I remember Heathkit schematics as being particularly well-drawn. I think a lot of the quality of the older drawings was that mechanical drawing was at that time a required engineering skill and something people did with great pride. A sloppy drawing indicated sloppy engineering. In Jules Verne's The Begum's Fortune (1879), the hero infiltrates into the enemy's Metropolis-like factory through outstanding mechanical drawing ability.
One of my pet peeves is the terrible automatically-generated logic diagrams one gets from logic synthesizers. IMO they're practically useless for anything but the simplest designs -- I'd much rather have textual equations.
@David, the diamond schematic in my comment doens;t use dots to indicate connections. Should it? That's another alway's debateable convention: dots or no dots. I prefer dots because sometimes having lies cross in unavoidable. When that occurs, a dot makes i clear that there's a connection. Some get around then by having only T interestions, avoiding crosses (+).
Definitely diamond, but not all CAD systems allow this.
Some CAD systems demand the dot to recognize the connection. For example, in TinyCAD without the dot a T intersection is not considered part of the same net; when highlighting that net the T branch does not highlight.
One nice thing in a CAD system is the ability to place simulation results and actual measured scope plots directly onto the schematic, in color. The art has come a long way since I was first forced to use Daisy instead of my pencil.
Speaking of bridge circuits. A press release with this digram just came to my inbox. A bridge with MOSFETs. Note the diamond bridge with the connections not always on the points. How would you redraw this schematic?
I'd run the nets connected to the LT4321 pins IN36 and IN78 around the outside of the bridges and connect them to the right-most points of the bridges. That leaves the inside of the bridges empty.
Alternatively, I'd consider rotatating the bridge transistors so they're in line and the gate connections are straight. I think this ends up with a visually simpler diagram, though you do lose the obviousness of the bridge.
I leave out the connection dots if they're inside a component symbol, and include them to join net wires that are outside component symbols. So if the bridge is a single 4-pin component, no dots. But if the bridge is composed of discrete diodes, then yes dots.
I don't like dots. I think that comes from my distant past when photocopiers were a bit "muddy" and a dot and a cross would look very similar. Fot that reason I use a half-moon "jump" where wires cross. However this is when I do my own (usually simple) schematics by hand or with MS Paint (luddite, aren't I?) With CAD programs you pretty much have to take what you get it seems, and the drawing style would hardly be a game changer....
My first engineering job had a requirement, from the military customer I beleive, that schematics not have dots. If lines cross, they do not connect nets. If a connection is desired, the vertical line must be offset and split into two Ts. They said the dots would get lost in mutliple photocopies. It made sense to me and I have adopted it for use over the last 30 years. I don't why, but when I see a schematic with little hoops where nets cross and don't connect, it makes me think of hobbyist versus professional.
The diamond looks the part if the package contains a bridge with four diodes. If the bridge is made from two SOT-23 packages each with a pair of diodes, then the Manhattan placement looks like the parts.
It looks like the schematic layout was the first step to the PCB layout. Like the "style" David A. describes with netnames on each component pin and nothing else, the schematic is a necessary evil in order to design the PCB.
For those of use who realize the importance of design reviews (even by yourself), and don't have the luxury of ATE but require air-breathing technicians to troubleshoot circuit boards, the time spent on schematic layout is paid back many fold.
Many many many years ago, while at a training session for schematic capture software, I asked about automatic off-page location references for networks. The instructor asked me why that was necessary, since the connection is defined. I had to explain the warm-body-troubleshooting scenerio.
As far as bypass cap locations, I want it to be easy to verify bypass caps during a design review. If having them at the primary symbol makes that area cluttered, then include a text note at the cap with the Ref Des of the associated IC. A similar issue are invisible (on the schematic) power and ground connections. If you don't want them on the primary gate of the IC, then have a power-connection gate, which is also a convenient location for the bypass cap.
The main reason to take time to create a 'clean' schematic is that it is more than a graphical netlist. It is both the design and the design's documentation. It's likely someone else will look at it, and the kind thing to do is make it easy for everyone else to quickly understand the designer's intent.
I've heard it said that confusing designs (both schematic and code) are likely a reflection of the designer's own confusion - not true in all cases, but ceratainly in some. My own take is that messy schematics and code are, basically, selfish - the designer doesn't care if they're clear to anyone else. And this can lead to real costs down the line. Taking the time to create a tidy schematic within the confines of page size, symbol size, and schedule will pay off in the long run, and reflect well on the designer.
Here, here! In the life of a schematic the engineer spends about 1% of his/her time with it. The rest of the time someone else has to read it and try and understand how the design works - and they usually have less education. It is CRITCAL that the development engineer take some time to make a clean schematic. It also goes a long way in helping the layout guy understand signal flow and layout.
I have to laugh sometimes at the way some schematics are done because it is usually a reflection of the way the development engineer thinks. If the schematic is a mess, the engineer doesn't usually think clearly or make clear decisions.
@JohnMMoore, I've heard it said that poor documentaion, especially code with little or no comments, is done for job protection. The designer wants to be the only person in the company who knows how the thing works. It's all about unique knowledge.
betajet, I disagree. Clear documentation makes it that much easier to handoff to another engineer. I personally ttry to make my documentation clear, especially firmware by adding tons of comments on the intent of the code. However, I have seen folks manage to stay in a job way longer than management desired, by purposefully writting obscure code. Schematics aren't so difficult to clean up, no matter how bad the original authors intentions were.
At one place I used to work all logic gates were drawn as boxes. No sense of the logic function, the only intent of the schematic was to create a netlist to create a PCB. The idea was that no competitor could use the schematic to figure out the logic. Nor could anyone else within that company.
That, of course, is what happens when the lawyers are let out of their cages.
This must be very recognizable by a lot of us folks: Yet another CAD company trying to sell us 'tools' that create schematic symbols from an FPGA pin list. You get these 'square blobs' full of 'pins' having absolutely no relation to the schematics that you currently are creating.
No thank you, not my cup of tea. To my opinion: Schematics are artwork and are as important as the PCB design itself: FPGA's should be represented in banks, just as they are internally organized.
For example, this I find an absolute shame: CAD companies selling their toolchains with schematic entry tools that really are from the '80's. Horrible. I used PCAD until a couple of years ago. I used it until they were invaded by the Chinese. Now -fully into Chinese hands- they force you to go to work 'in the cloud'. Well, I followed StarTrek for years and I know how unpredictable 'clouds' can be, so thank you, I miss another cup of tea.
[COMPUTING IN THE CLOUD IS NOT A WISE IDEA] (c) Rob Gongrijp, a former Dutch hacker
Then, Cadence... what ??? !!! Orcad schematics? From the 80's indeed. They should be ashamed of themselves. You cannot even recognize LVDS pairs besides to couple them inside a 'spread sheet'. Helpful indeed, those spreadsheets, but the schematics *should* tell you the full story as a lot of people here already mentioned. And you have to know that they *have* proper schematic entry tools. Even PCAD is more modern looking than Orcad. People tend to make these 'label schematics', unreadable, I hate those.
I have the feeling that 2D CAD just is a big money maker and they don't care a ^#$%@^ of our struggle to get something properly on paper. Beeing in the industry for more than 25 years this is one of my frustration points. So, thanks for bringing this up.
Blog Doing Math in FPGAs Tom Burke 15 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...