back to Article List
The smoke has not even cleared, and they know what the problem is. It was supposed to be a celebratory moment for the team, plugging in the first board from the first shipment. Instead, the room is as silent as a morgue.
The engineer steps forward to do the postmortem and immediately sees the issue. The integrated circuit (IC) has a pinhole melted into the surface, telling the story of the destruction within. (Usually this doesn’t melt the part; it just quietly kills it and is more of a noise thing.) She traces back along the board, and the decoupling capacitor is nowhere to be found. A completely predictable voltage spike overcame the fragile circuit. The engineer knows that she put the capacitor in place. However, on closer examination, it is not close enough to the IC pad to make a difference. Everyone turns to the PCB designer.
“But I put it right where the schematic said to!” says the designer.
The fix is easily implemented. It takes fifteen minutes to produce a new design. Unfortunately, the break room already has an ample supply of coasters, and that’s all this batch of boards can now be used for. The project will lose days and dollars.
How did this confusion come about?
When engineers start to put together projects, they are not just making circuits. They are writing a message to the PCB designer. Their work product—and thus, their process—needs to be a helpful part of a team effort. The schematic is, at first, the space in which an engineer does their thinking. However, by the time they hand it off to the designer, it needs to be a clean, comprehensible document that eliminates vagaries.
In the nightmare scenario above, the designer ends up in the crosshairs, but what could the engineer have done to prevent the problem and save that first run of boards from a life of coffee stains?
Good schematics are good team play.
Every day at Sunstone, we get calls from teams that have sent a design in prematurely and need to make a last-minute change. If they get to us in time, we will pull the design back. At the very least, they may lose some productive days fixing and resubmitting the design.
We all know that there is a best practice for the work, but we slip from it, often in the effort to save time. In teams that I work with, I want the mindset to be “I was in a hurry, so I did everything right.” What is right? It is starting at high-altitude block diagrams and then breaking each block into one or more schematic sheets, checking flow and accuracy carefully, and then designing the board.
Of course, the engineer and the designer go over the design carefully to make sure that it matches the specs, right? One would hope so, but busy people on tough deadlines can easily decide to lean on the automation tools.
Designers don’t read minds. They read schematics. Engineers need to make that document as functional as possible. The engineer may understand implicitly the locations for all their bypass capacitors. They end up listed in the corner of one page, but that relies on the designer to interpret that intent and properly place the elements. A more thoughtful engineer will locate devices in roughly the manner of the final design to help the designer avoid bad interconnects, placement assumptions, or other errors.
In addition, it never hurts to provide explanatory notes about the elements. I have never heard a designer say that the engineer provided too much guidance for their work.
A key element is to utilize good naming conventions for connections (net names). We all know that the default automated labels that our design software provides are far from intuitive. Help the designer avoid embarrassing connection mistakes that will slow the project down by creating—and consistently using—connection labels a human can understand.
Speaking of interconnects, the designer’s job is sure easier if they have software on their side. Some engineers—again, often thinking they are too busy for best practices—will do what I call “working in expert mode.” They give implicit connections using port symbols for the entire schematic, thereby creating no trail for the designer to follow. While it saves the engineer a couple of minutes, that time is effectively lost while the designer sorts out the nest of connections.
The software tracks and confirms those connections for a reason. It may feel like an obstacle for the engineer, but for the overall project, these tools are a lifeline.
Everyone runs the design rule check (DRC), but not everyone actually resolves those errors. It is all too frequent for “just documentation” issues that won’t theoretically affect the performance of the board to be left in place.
Over time, these errors build up and create a fog of confusion that makes it hard to maintain quality. A team should expect that every build is accompanied by a DRC report that reads “no warnings and no violations.”
Well-designed schematics pay off not just for the current project but on into the future. If your schematic is nice to look at and clear, you and other engineers can utilize blocks for other similar projects. Teams that commit to good schematic practices win the long game.
We are all thinking about making great final products. Designers want to make great boards. Engineers want to make great schematics. We also need to think about making the work of the next person easier to ensure that they do not make avoidable errors. Everyone, from management to manufacturing, suffers from go-it-alone engineering and benefits from clean schematics.
Which one would you rather try to follow? The one on the right looks neater, but you can easily trace the interconnects on the one on the left.
We always love to hear from you.
Contact us at 1-800-228-8198 or via email at email@example.com