How to lay out a schematic for review? Please critique

Question

So, because I haven't posted a schematic for review before, I have no idea how to do it. Apparently, my previous attempt was poor. I got some actionable feedback, but I'm looking for more!

I would be very happy if you could give me concrete feedback on what I can do with this schematic to make it more easy and straightforward to review.

The main functions are: - input from wall wart - LDO regulated to 6V - provides 5.15V on VCC when connected - MOSFET switched current to a Li-ion battery - output of battery (as well as LDO output) stepped-up to 5V to VCC

The charge voltage will be sensed through one line, and PWM controlled through another line.

As a secondary concern, I assert that the dual input to VCC is safe, because if both systems are running at the same time, D2 and the fact that Vsense at R25 is higher than target will essentially just "idle" the switching controller.

https://watte.net/charger-switcher-schematic.png

Answer 1

I agree with much of what Fake said, but some of his points seem to be religious issues with little validity.

1. No, do use net labels. If it can be reasonably done then it's better to connect points directly with lines. However, that's not always possible or reasonable. Obviously it can't be done with multiple sheets, and a messy ratsnest of wires is worse than a few carefully chosen "air wires". Labeling nets is one way to show connections. Everything with the same name is assumed to be connected, and most software will enforce this anyway. Fot that reason it is a good idea to use net labels generated by the software from the name in the database rather than you typing it in. If separate sections of the net ever get disconnected or separately renamed by accident, the software will automatically show this since the name shown comes from the actual net name, not something you type in separately. This is a lot like a variable in a computer language. You know that multiple uses of the variable symbol refer to the same variable.

   Another good reason for net names is short comments. I sometimes name and then show the names of nets only to give a quick idea what the purpose of that net is. For example, seeing that a net is called "5V" or "MISO" could help a lot in understanding the circuit.

2. Yes, show pins of ICs in position relevant to their function, NOT JUST HOW THEY HAPPEN TO BE ON THE CHIP. One important purpose of a schematic is to convey a circuit to others so they can understand it. ICs with pins in physical pin order are difficult to understand. Some people use the excuse that this aids in debugging, but with a little thought you can see that's not true. When you want to look at something with a scope, which question is more common "I want to look at the clock, what pin is that?" or "I want to look at pin 5, what function is that?". In some rare cases you might want to go around a IC and look at all the pins, but the first question is by far more common.

   Physical pin order layouts obfuscate the circuit and make debugging more difficult. Don't do it.

3. Yes, in general it is good to put higher voltages towards the top, lower voltages towards the bottom, and logical flow left to right. That's clearly not possible all the time, but at least a general higher level effort to do this will greatly illuminate the circuit to those reading your schematic.

   This also causes common subcircuits to be drawn similarly most of the time. Once you get more experience looking at schematics, these will pop out at you and you will appreciate this. If stuff is drawn every which way, then these common circuits will look visually different every time and it will take others longer to understand your schematic.

   Good schematics show you the circuit. Bad schematics make you decipher them.

4. Yes, spend some time with placement reducing wire crossings and the like. The recurring theme here is clarity. You should be trying to help people understand the circuit easily, not make them figure it out despite the schematic.

5. No, don't use extra long names. Again, the point is clarity. No names is no information, but lots of long names are clutter, which then decreases clarity. Somewhere in between is a good tradeoff. I don't want to see "8 MHz clock to my PIC", when simply "CLK", "CLOCK", or "8MHZ" would do.

6. No, do use all caps for net names and pin names. Pin names are almost always shown upper case in datasheets and schematics. Various schematic programs, Eagle included, don't even alow for lower case names. One advantage of this, which is also helped when the names aren't too long, is that they stick out in regular text. If you do write real comments in the schematic, always write them in mixed case but make sure to upper case symbol names to make it clear they are symbol names and not part of your narrative. For example, "The input signal TEST1 goes high to turn on Q1, which resets the processor by driving MCLR low.". In this case it is obvious that TEST1, Q1, and MCLR refer to names in the schematic and aren't part of the words you are using in the description.

7. CLEAN UP TEXT PLACEMENT. Schematic programs generally plunk down part names and values based on a generic part definition. This means they often end up in inconvenient places in the schematic when other parts are placed nearby. Fix it. That's part of the job of drawing a schematic. Your schematic above is particularly guilty of this. There are part names and values overlapping all sorts of stuff and are even sideways in a lot of places. Again, the most important point is clarity.

   There is another point in this case. A sloppy schematic shows lack of attention to detail and is a irritation and insult to anyone you ask to look at it. Think about it. It says to others "Your aggrevation with this schematic isn't worth my time to clean it up" which is basically saying "I'm more important than you". That's not a smart thing to say in many cases, like when you are asking for free help here, showing your schematic to a customer, teacher, etc. Neatness and presentation count. A lot. You are judged by your presentation quality every time you present something, whether you think that's how it should be or not. In most cases people won't bother to tell you either. They'll just hire someone else, go on to answer a different question, not look for some good points that might make the grade one notch higher, etc.

Answer 2

You're using net-labels.

Net labels are horrible from a maintainability standpoint. I see at least one net (Bat+), where there is no reason to be using a net label.

Net labels are the schematic equivalent of GOTO. Basically, it lets one point on a schematic connect to any number of other points on the schematic, while not providing any clear indication of how many points it is connected to, or where those points are.

If I am working on someone else's project, and they use net labels, it can be very hard tell what is connected to what, particularly if the schematic is spread over several sheets. Once you have many sheets (5+), it effectively becomes unmaintainable. It's the schematic equivalent of spaghetti-code.

The proper way to manage multiple-sheet projects is unfortunately not available in eagle. It's called Hierarchical Design. Effectively, each schematic page is used as a meta-component, and you have a top-level schematic that describes the interconnections between sheets. This lets you determine everything that is connected to any net, by following the wires. Any wire leaving a sheet only goes to one place, the top sheet. That sheet may have it connecting to multiple other sheets, but it's clearly shown, rather then implicit, as net labels are.

I know you can do this in Altium Designer, and I believe it is also possible in Cadence Allegro, though I have not use cadence much.

^{To be honest, about the only feature Eagle has going for it is it's cheap. Many of the other EDA packages out there are so much nicer to use, and produce much better looking drawings. I don't think I've ever seen a drawing done with Eagle that wasn't ugly. At best, they're just unpleasant. At worst, they're a god-awful nightmare.}

---

Also, you are drawing your components with the pins physically placed where they are on the actual device.

The whole point of a schematic is to abstract the function of a circuit away from the nitty-gritty details of which pin goes where. Forcing the schematic to physically match the devices makes the schematic messy, and harder to read. The whole purpose of modern EDA software is to let the computer, which is much better at handling all the meticulous details of what wire is connected to what, do the correlations for you.

Generally, you want you Vcc pins on the top, your ground pins on the bottom, your inputs on the left, and your outputs on the right.

I tend to be a little free with pin placement, optimizing schematic entities to minimize the number of wires crossing. It makes the schematic much easier to read.

For example, here is how I would draw your boost converter (I had to stare at it for a while to figure out what it was ^{_{And now I noticed you stated what it was in the question. DERP!}}):

The position of the main rectifier diode should make it immediately apparent now that it's a boost converter.

Also, the feedback is much easier to see.

Lastly, if you only have the battery connected to a few places, don't even use a power-port for it. Since it's only going a few places, use a wire.

^{Incidentally, what part is this? Now that I drew it up in my schematic library, I might as well label it properly, and maybe even use it in the future.}

---

Other silly stuff:

• C5 is 470 pF - I assume this is a ceramic? If so, don't use the schematic entity for a polarized cap. It should be two straight lines, not one straight, and one curved.

• While matching the part datasheet on pin naming is almost always a good idea, there are a few edge-cases where I think being a little bit more verbose can be tremendously helpful. If I'm doing a schematic I want to be really easy to comprehend (Or feel a bit like doing some overkill), I will actually copy the block diagram of the part into the drawing for the component in my library: