Schematic Drafting Standards

[16bitanalogue]

Hello Everyone,

I am currently in the process of creating best practices for schematic and PCB layout. There are a couple of great posts regarding this topic on this forum and on Electronics Stack Exchange. Just a few:

https://electronics.stackexchange.com/questions/28251/rules-and-guidelines-for-drawing-good-schematics
https://www.eevblog.com/forum/projects/the-best-schematic-layout-standards/

I am about to go into battle with, as a term of endearment, Boomer executives who never had experience with day-to-day engineering tasks and will simply default to "Back in my day 30 years ago...so do it like we did." I would like something more than "read this excellent post by experienced engineers" because that is exactly how they perceive: as an "Internet post."

So the pertinent question: is there an IEEE or ANSI standard for electronic schematic drafting standards that I can use as a reference? My Google-Fu has failed me.

[tggzzz]

Hello Everyone,

I am currently in the process of creating best practices for schematic and PCB layout. There are a couple of great posts regarding this topic on this forum and on Electronics Stack Exchange. Just a few:

https://electronics.stackexchange.com/questions/28251/rules-and-guidelines-for-drawing-good-schematics
https://www.eevblog.com/forum/projects/the-best-schematic-layout-standards/

I am about to go into battle with, as a term of endearment, Boomer executives who never had experience with day-to-day engineering tasks and will simply default to "Back in my day 30 years ago...so do it like we did." I would like something more than "read this excellent post by experienced engineers" because that is exactly how they perceive: as an "Internet post."

So the pertinent question: is there an IEEE or ANSI standard for electronic schematic drafting standards that I can use as a reference? My Google-Fu has failed me.

Create the schematic for the readers' benefit, not for your convenience.

Signal flow left to right and top to bottom, except for feedback paths.

Use conventional symbols for components, which means never having a schematic symbol which has all the pins in the same position as the component on the PCB (but do put the pins on the schematic!).

Use the standard "design patterns" for subcircuits; that aids rapid comprehension.

Don't force fit everything onto one sheet.

Use hierarchical diagrams where it aids comprehension.

Explicitly connect all components with wires; don't draw an IC, name an otherwise unconnected net, and expect readers to join all the names together. Exception: power supplies. EDIT: group similar signals (e.g. data or addresses) into a bus, and label where they enter/exit the bus. That both "connects all" and "minimises spaghetti clutter".

Don't bother to put digital IC decoupling capacitors next to the IC. Do put analogue circuit decoupling capacitors next to the specific IC they are decoupling.

[exmadscientist]

is there an IEEE or ANSI standard for electronic schematic drafting standards that I can use as a reference?

Nope. And where they might exist, they are hopelessly outdated or just plain trash.

(There are such standards for individual schematic symbols, and they're pretty decent. But not for schematics as a whole.)

Be careful here. This sort of stuff is always a mess, with tons of bikeshedding. It is generally a big fight. In a previous life I was fortunate enough to work with a senior consultant who shared my mindset, and the two of us were senior enough (and the rest of the engineers apathetic enough, at least about this; note that we only tried this after a certain person left!) that we just forced through a nice set of standards. I still have a copy, and can dig them up (I actually continue to work to this standard where no other rules exist, which is common; it's a good standard!) I could scrub it and send it over, but it's written "by professionals for professionals": it fills in the parts that need filling in, not the obvious bits or the never-any-agreement bits. I'm not willing to post it publicly, though, so it's probably no help to you either way.

The most important thing is that the schematic should be filled with lots of explanations. Many places require a "theory of operation" document. My opinion is that, except in rare cases, this should just be written directly on the schematic. (I think this would have been the norm since the beginning if CAD, with its infinite editability, had come about before vellum. Which it didn't.) This makes for schematics dense with words and explanation... explanation placed right where and when you need it. This is amazing for smaller projects and teams, especially teams of one. It is not as good at larger companies, both practically ("I don't wanna read a schematic, I'm not an electrical engineer"), logistically (three people cannot easily edit one file), bureaucratically ("where is the XZ-808 document? no, you cannot use a schematic as an XZ-508! I don't care if it's one sentence, we can't release without an XZ-508"), and worst of all culturally ("in 1959 we didn't do that, so we're not doing that today!").

So... tread carefully.

[exmadscientist]

means never having a schematic symbol which has all the pins in the same position as the component

Hey now! There was that one, one!, time where the IC guys laid out the pinout perfectly! Once... maybe twice... in all these years... that was a nice project, I miss that part....

No, but seriously, never do this. One of my tells for low-quality schematics is when schematic pin arrangement matches the part physical pin arrangement. Nothing good comes of this.

(Now I do often match them in the library editor when I am drawing the symbol, or otherwise match something in the datasheet, whatever is best for easiest cross-checking. I then rearrange them for maximum schematic clarity before finishing the library component.)

Explicitly connect all components with wires; don't draw an IC, name an otherwise unconnected net, and expect readers to join all the names together. Exception: power supplies.

I would also say large connectors are an exception. Too many times I see a giant rat's-nest next to a connector and just have to trace wires through it. Trace labels or ports are not good but they are sure as hell better than a rat's-nest.

[tggzzz]

means never having a schematic symbol which has all the pins in the same position as the component

Hey now! There was that one, one!, time where the IC guys laid out the pinout perfectly! Once... maybe twice... in all these years... that was a nice project, I miss that part....

Ah, but was the schematic symbol outline merely a rectangle without embellishments. And did the power supply pins need to be shown? 

No, but seriously, never do this. One of my tells for low-quality schematics is when schematic pin arrangement matches the part physical pin arrangement. Nothing good comes of this.

Precisely. I expect that the designer intended that such schematics would be implemented on solderless breadboards. (Caution: rathole ahead!)

(Now I do often match them in the library editor when I am drawing the symbol, or otherwise match something in the datasheet, whatever is best for easiest cross-checking. I then rearrange them for maximum schematic clarity before finishing the library component.)

Explicitly connect all components with wires; don't draw an IC, name an otherwise unconnected net, and expect readers to join all the names together. Exception: power supplies.

I would also say large connectors are an exception. Too many times I see a giant rat's-nest next to a connector and just have to trace wires through it. Trace labels or ports are not good but they are sure as hell better than a rat's-nest.

Do group similar signals together in a bus, and label wires as they enter/exit from the bus. That satisfies both "connect everything" and "minimise spaghetti".

Don't group dissimilar signals in a single bus. Possible exception: bus control signals such as R/W, CS, EN are "similar".

[16bitanalogue]

is there an IEEE or ANSI standard for electronic schematic drafting standards that I can use as a reference?

Nope. And where they might exist, they are hopelessly outdated or just plain trash.

(There are such standards for individual schematic symbols, and they're pretty decent. But not for schematics as a whole.)

That stinks. I only found references to schematic symbols myself. The previous posts mentioned drafting standards [for schematics], so I was hoping by chance these actually existed.

Be careful here. This sort of stuff is always a mess, with tons of bikeshedding. It is generally a big fight. In a previous life I was fortunate enough to work with a senior consultant who shared my mindset, and the two of us were senior enough (and the rest of the engineers apathetic enough, at least about this; note that we only tried this after a certain person left!) that we just forced through a nice set of standards.

I work at a relatively small company. My colleagues and myself have enough experience and pull to argue for a decent set of company standards. I agree that it is always a battle, but as long as we have a good footing to articulate a 'why' and if there is a disagreement follow up with 'what is another solution?'. Those higher-ups will often acquiesce to our view if they cannot present their own reasoned counter-point.

I still have a copy, and can dig them up (I actually continue to work to this standard where no other rules exist, which is common; it's a good standard!) I could scrub it and send it over, but it's written "by professionals for professionals": it fills in the parts that need filling in, not the obvious bits or the never-any-agreement bits. I'm not willing to post it publicly, though, so it's probably no help to you either way.

You can send them to me in an email if you want. I have always had to learn by the seam-of-my-pants, and never had a good mentor for this particular topic. I always refenced what I could and compiled practices off 'The Internet'.

The most important thing is that the schematic should be filled with lots of explanations. Many places require a "theory of operation" document. My opinion is that, except in rare cases, this should just be written directly on the schematic. (I think this would have been the norm since the beginning if CAD, with its infinite editability, had come about before vellum. Which it didn't.) This makes for schematics dense with words and explanation... explanation placed right where and when you need it. This is amazing for smaller projects and teams, especially teams of one. It is not as good at larger companies, both practically ("I don't wanna read a schematic, I'm not an electrical engineer"), logistically (three people cannot easily edit one file), bureaucratically ("where is the XZ-808 document? no, you cannot use a schematic as an XZ-508! I don't care if it's one sentence, we can't release without an XZ-508"), and worst of all culturally ("in 1959 we didn't do that, so we're not doing that today!").

Generally I think most of this is covered in a User's Guide: theory of operation of the board, schematic, PCB layout in PDF (gross, but what can you do?), trouble shooting tips, etc. But your last comment, that hits home where I am currently residing. It's laughable. Work as in life is a balance, but not every topic should be a battle because "We did" or "We did not" so something decades ago. This is true for those who only worked at one company all throughout their career.

Overall, excellent advice.

[SCSKITS]

With large parts it helps to break up the part into sections, for example with MCUs by GPIO port, regardless of whether the pins are adjacent.
I do the same with the banks in EPLDs/FPGAs where possible.

[coppice]

Don't bother to put digital IC decoupling capacitors next to the IC. Do put analogue circuit decoupling capacitors next to the specific IC they are decoupling.

The point you are trying to make is good, but that's a bad way of putting it. Decoupling is usually a bunch of fairly large capacitors providing a generally tame supply rail for many parts, plus a bunch of smaller capacitors close to key parts. Some of those are analogue and some are not. When a decoupling capacitor is intended to be tightly associated with a particular part, draw it that way. When its part of the general decoupling don't visually associate it with any particular part on the schematic.

[Kim Christensen]

Generally I think most of this is covered in a User's Guide: theory of operation of the board, schematic, PCB layout in PDF (gross, but what can you do?), trouble shooting tips, etc.

One thing I've found very useful when trying to understand complex equipment and circuitry are block diagrams.
Detailed text based descriptions are particularly useful if some part of the circuit is unconventional or odd. Not really needed otherwise.

Be careful here. This sort of stuff is always a mess, with tons of bikeshedding. It is generally a big fight.

Thanks for that link. 

[Bud]

And did the power supply pins need to be shown? 

They should be. The reason is there may be No Connect (NC) pins on the package, which are often not shown on the schemaric symbol. If power supply pins are not shown either , you won't know what they are and would need to check the datasheet. This is in general, as there maybe trivial cases like 74 logic where power pins are well known.

[coppice]

And did the power supply pins need to be shown? 

They should be. The reason is there may be No Connect (NC) pins on the package, which are often not shown on the schemaric symbol. If power supply pins are not shown either , you won't know what they are and would need to check the datasheet. This is in general, as there maybe trivial cases like 74 logic where power pins are well known.

In the heyday of the 74 family showing the supply pins didn't make sense, especially since most of them contained multiple copies of a functional block, which at the initial schematic level were not bundled. The bundling happened through back-propagation after PCB layout. This has largely gone away, as chip complexity has increased. We are now in an era where there is no standardisation of power pins across a range of parts, a huge number of parts have multiple power rails, and the whole issue of the power flowing to a chip is far more complex. A schematic needs to tell you what is really going on with the power.

[tggzzz]

And did the power supply pins need to be shown? 

They should be. The reason is there may be No Connect (NC) pins on the package, which are often not shown on the schemaric symbol. If power supply pins are not shown either , you won't know what they are and would need to check the datasheet. This is in general, as there maybe trivial cases like 74 logic where power pins are well known.

That response ignores the context in which my comment was made. Please just use the "quote" button and don't remove too much context.

Of course the power supply pins have to be shown somewhere on the schematic. If they aren't then they wont be in the netlist and won't be on the PCB!

[tggzzz]

And did the power supply pins need to be shown? 

They should be. The reason is there may be No Connect (NC) pins on the package, which are often not shown on the schemaric symbol. If power supply pins are not shown either , you won't know what they are and would need to check the datasheet. This is in general, as there maybe trivial cases like 74 logic where power pins are well known.

In the heyday of the 74 family showing the supply pins didn't make sense, especially since most of them contained multiple copies of a functional block, which at the initial schematic level were not bundled. The bundling happened through back-propagation after PCB layout. This has largely gone away, as chip complexity has increased. We are now in an era where there is no standardisation of power pins across a range of parts, a huge number of parts have multiple power rails, and the whole issue of the power flowing to a chip is far more complex. A schematic needs to tell you what is really going on with the power.

Agreed.

Whether such PSU pins should be clumped together on a separate "PSU schematic", or intermixed with signals is not something with a single correct answer. Good taste is the key, in conjunction with "what makes it easiest for a new reader to understand what is intended, and why".

Note that Bud's comment represents a strawman argument (it snips the relevant context in which I made my statement).

[tggzzz]

I work at a relatively small company. My colleagues and myself have enough experience and pull to argue for a decent set of company standards. I agree that it is always a battle, but as long as we have a good footing to articulate a 'why' and if there is a disagreement follow up with 'what is another solution?'. Those higher-ups will often acquiesce to our view if they cannot present their own reasoned counter-point.

If that's the case, why not just agree amongst yourselves?

What is lost by not having a company standard?

[aeg]

See also "how to draw schematic diagrams" in Horowitz & Hill - The Art of Electronics, appendix B in the third edition or appendix E in the second edition.

[16bitanalogue]

I work at a relatively small company. My colleagues and myself have enough experience and pull to argue for a decent set of company standards. I agree that it is always a battle, but as long as we have a good footing to articulate a 'why' and if there is a disagreement follow up with 'what is another solution?'. Those higher-ups will often acquiesce to our view if they cannot present their own reasoned counter-point.

If that's the case, why not just agree amongst yourselves?

What is lost by not having a company standard?

As the team grows there needs to be a sense of uniformity. Generally:
1. Always do a, b, c
2. Never do x, y, z
3. Use judgement for 1, 2, 3

It's a small company where the executives for the first time in decades are very close to the day-to-day; however, they try to enforce outdated methodology with documentation, process, and engineering methods that they used when they were individual contributors back when Marty was driving 88 MPH.

See also "how to draw schematic diagrams" in Horowitz & Hill - The Art of Electronics, appendix B in the third edition or appendix E in the second edition.

I have the second edition on by bookshelf. I will include this!

[tggzzz]

See also "how to draw schematic diagrams" in Horowitz & Hill - The Art of Electronics, appendix B in the third edition or appendix E in the second edition.

I have the second edition on by bookshelf. I will include this!

Obvious point: check you agree with what they say! Nobody is above critical appraisal

ISTR seeing some of their schematics with with everything crammed into one schematic

[Marco]

Create the schematic for the readers' benefit, not for your convenience.

Except for opamps, everyone flips those over.

[tggzzz]

Create the schematic for the readers' benefit, not for your convenience.

Except for opamps, everyone flips those over.

?yeht oD

I don't understand what you mean by that, in that context.

[nctnico]

means never having a schematic symbol which has all the pins in the same position as the component

Hey now! There was that one, one!, time where the IC guys laid out the pinout perfectly! Once... maybe twice... in all these years... that was a nice project, I miss that part....

No, but seriously, never do this. One of my tells for low-quality schematics is when schematic pin arrangement matches the part physical pin arrangement. Nothing good comes of this.

Well, I assume you never debugged / verified a circuit then. In reality it greatly depends on the part whether it is feasible to draw the part like it is in the schematic. If you can, do draw the part as it is. When doing debugging / verification, all you need to know where to place a probe is the schematic and no need to count pins as you can tell by the external arrangement of the components which pin is which  in many cases. This saves a lot of time (which equals money).

Another good reason to draw a part in its physical form is that you have a good overview whether all pins have been assigned.

Actually, if the schematic looks like a mess when you draw a part in its physical form, the part is likely going to be a nightmare to get routed on the board anyway. So this is a good first sign of how difficult the board layout is going to be. Maybe a different part is more suitable.

[nctnico]

And did the power supply pins need to be shown? 

They should be. The reason is there may be No Connect (NC) pins on the package, which are often not shown on the schemaric symbol. If power supply pins are not shown either , you won't know what they are and would need to check the datasheet. This is in general, as there maybe trivial cases like 74 logic where power pins are well known.

That response ignores the context in which my comment was made. Please just use the "quote" button and don't remove too much context.

Of course the power supply pins have to be shown somewhere on the schematic. If they aren't then they wont be in the netlist and won't be on the PCB!

This is not how it used to work in the old days. Many 74 and CMOS series logic libraries still have hidden power pins which are not shown on the schematic anywhere. These are silently tied to net names like VCC, VEE, GND, VSS, etc. which are then automatically connected in the netlist. This is nice and dandy when your circuit only has / needs a 5V 300A power supply but those days are long gone.

[coppice]

This is not how it used to work in the old days. Many 74 and CMOS series logic libraries still have hidden power pins which are not shown on the schematic anywhere. These are silently tied to net names like VCC, VEE, GND, VSS, etc. which are then automatically connected in the netlist. This is nice and dandy when your circuit only has / needs a 5V 300A power supply but those days are long gone.

Pins obscured on the schematic were always a PITA. Most of the time older chips had the supply pins in very predictable places, but when they didn't you could end up digged out data sheets, checking packaging options, etc, trying to find where the power should be when debugging.

[nfmax]

means never having a schematic symbol which has all the pins in the same position as the component

Hey now! There was that one, one!, time where the IC guys laid out the pinout perfectly! Once... maybe twice... in all these years... that was a nice project, I miss that part....

No, but seriously, never do this. One of my tells for low-quality schematics is when schematic pin arrangement matches the part physical pin arrangement. Nothing good comes of this.

Well, I assume you never debugged / verified a circuit then. In reality it greatly depends on the part whether it is feasible to draw the part like it is in the schematic. If you can, do draw the part as it is. When doing debugging / verification, all you need to know where to place a probe is the schematic and no need to count pins as you can tell by the external arrangement of the components which pin is which  in many cases. This saves a lot of time (which equals money).

Another approach is to put a package outline, with appropriate PIN numbers e.g. at the corners, as a schematic “comment”. This works for some packages, but not for others like BGA. Comments on circuit diagrams can help a lot

[tggzzz]

means never having a schematic symbol which has all the pins in the same position as the component

Hey now! There was that one, one!, time where the IC guys laid out the pinout perfectly! Once... maybe twice... in all these years... that was a nice project, I miss that part....

No, but seriously, never do this. One of my tells for low-quality schematics is when schematic pin arrangement matches the part physical pin arrangement. Nothing good comes of this.

Well, I assume you never debugged / verified a circuit then. In reality it greatly depends on the part whether it is feasible to draw the part like it is in the schematic. If you can, do draw the part as it is. When doing debugging / verification, all you need to know where to place a probe is the schematic and no need to count pins as you can tell by the external arrangement of the components which pin is which  in many cases. This saves a lot of time (which equals money).

Another good reason to draw a part in its physical form is that you have a good overview whether all pins have been assigned.

Actually, if the schematic looks like a mess when you draw a part in its physical form, the part is likely going to be a nightmare to get routed on the board anyway. So this is a good first sign of how difficult the board layout is going to be. Maybe a different part is more suitable.

Absolutely not! What on earth does "draw the part as it is" mean?!

The purpose of the schematic is to expose the design. That guides understanding what you should observe when you place a probe on a component.
The PCB is one implementation of the design, and purpose of the PCB component overlay is to expose the components on the PCB.

The logical conclusion of your contention is to omit the schematic and use only the PCB component overlay. After all, all you need to do is know which point to probe - don't you? (Hint: no!)

[tggzzz]

means never having a schematic symbol which has all the pins in the same position as the component

Hey now! There was that one, one!, time where the IC guys laid out the pinout perfectly! Once... maybe twice... in all these years... that was a nice project, I miss that part....

No, but seriously, never do this. One of my tells for low-quality schematics is when schematic pin arrangement matches the part physical pin arrangement. Nothing good comes of this.

Well, I assume you never debugged / verified a circuit then. In reality it greatly depends on the part whether it is feasible to draw the part like it is in the schematic. If you can, do draw the part as it is. When doing debugging / verification, all you need to know where to place a probe is the schematic and no need to count pins as you can tell by the external arrangement of the components which pin is which  in many cases. This saves a lot of time (which equals money).

Another approach is to put a package outline, with appropriate PIN numbers e.g. at the corners, as a schematic “comment”. This works for some packages, but not for others like BGA. Comments on circuit diagrams can help a lot

I've never seen that, but that contention holds water.

Comments can be overdone and underdone. Good taste is required, and in this context good taste is whatever helps a person trying to understand the schematic.