There are a million ways to review a schematic, so there can be no 'correct' way. The complexity of the circuit, the risk tolerance and schedule of the project, along with the knowledge and available time of the reviewer will dictate how intense a review can be. With all of these variables, I won't waste any time with an article on '10 Steps to a Perfect Schematic Review.' However I will offer some notes on what I've found to work time and time again.
As with much of life, the most important point to bear in mind is humility.
There is always an error. Always. It might be small, fixable, and not noticed until the 5th revision of a board, but it is there. This is helpful to remember for two reasons; expecting perfection from anyone will inevitably disappoint, and the presence of errors will keep the reviewer attentive and vigilant when facing a sea of information.
Collect the required material.
Most of the 5 pieces of documentation detailed below should be provided by the original designer at varying levels of completion. No design documentation is perfect, so this list is made more of 'goals' than 'itemized requirements' and it may exclude some information needed for a specific design. Because of this, a reviewer should never be shy about asking for more information to aid understanding.
- The Completed, Up-To-Date Schematic
One would be amazed at how hard this can be to acquire. There is no point in reviewing a schematic that is in development, so this is a must.
- Block Diagram
This is helpful to understand where each part fits in the big scheme of things. If a reviewer doesn't understand how a part is used, it will be impossible to determine if it will work as expected. Every IC should be included in the block diagram somewhere so the reviewer will know in which functional block it belongs.
- Design notes and calculations from the designer
Ideally the designer will have kept notes such as 'from the equation on page 23 of the datasheet, R1 and C1 were calculated to be _____ and _____.' This may sound like a lot of work for the designer, but everyone will be glad that it is available when there are fewer people second guessing confusing values.
- Datasheets from all parts used in the design
The easier it is to access the information in datasheets, the more likely the reviewer will check the little things. Each reviewer should have a set of datasheets (digital or print) within arm's reach while reviewing. Note that it is good to have at least one person get their own copy of fresh datasheets to prevent a mistake from stale part specs from making it into the design.
- A Blank Notepad
This is where the magic happens. As the reviewer goes through the design, there needs to be a place to keep track of everything that was checked and found to be both correct and incorrect.
My Review Process
Labeled 'my' process because asking an engineer to use another person's process is akin to proposing a wife-swap. Some people may be into it, but it is generally a weird, horrible idea. However if you'd like to use some of the steps my process and I employ, it just might make you better with your process.
I spend time to gain an understanding of the system and the requirements.
Sometimes this includes a few discussions with the designer. Since he or she knows more than I do, I am strictly trying to get a grip on how the part was designed and never bring up criticisms. Once I know how it was intended to work I will independently examine the design to come up with well thought out criticisms and corrections for the review meeting.
Using the block diagram and my understanding, I write a list of things that need to be checked to guide my organization.
I will decide my favorite circuit flow and write a list of subsystems to check based on the block diagram ensuring that I will leave no part or section unchecked.
Next comes the 'meat' of the review. I go through each block, part by part, and ask myself, “If I needed to use this part to complete this job, how would I design it?”
It is important to write each question, answer, and calculation in the notebook since it will likely come up more than once. Also, small notes, problems, and questions for the designer should be written in red so they are not missed. At the very least, I find myself asking the following questions:
a. Check each pin on the part. Is it going where it should? Searchable PDFs are great for finding all instances of node names.
b. Check all of the supporting part calculations. Time constants, resistor ratios, etc...
c. Are the power rails connected correctly with proper decoupling?
Look back through the schematic and the organization list (from step 2) to be sure every part, connection, and functional block has been checked. I am always amazed at how many parts I would have missed without this step.
The Review Meeting
In order to go over the review findings, bring up questions, and duke it out over things such as a resistor tempco spec, the designer and reviewer(s) need to meet. With clear feedback from the reviewer(s), this meeting can be fast paced, even if long. To keep it moving, all comments, questions, and suggestions should be related to finding and correcting errors. No jibber jabber about 'Another good way to do it would be....' Those comments are best saved for the bar after work. The singular goal here is to build up the deliverable.
The Deliverable
This is what it is all about – creating positive change in a design before it gets built. The deliverable should be a simple spreadsheet itemizing the problems and how they will be fixed. An example can be found below:
| Problem Description | Corrective Action | Assigned To | Due |
|---|---|---|---|
| On page 3 R314 will overheat in some situations | Change R314 from an 0805 SMT to a 1210 SMT | Jim Bob | 8/22/11 |
| On page 3 U23 has one of the op amp inputs left floating | Connect the op amp as a buffer with the input grounded | Johnny Ray | 8/22/11 |
Looking back on this article, it may seem like a long way to go to get to the all-important deliverable. But as with anything else, once an engineer masters the process it becomes faster and easier to get through the steps and catch the nasty problems before they make it to the board house or even the CAD department. The reward? Finding a mistake that saves tens of thousands of dollars is a sure way to become a hero.
I'm certain there are things that other engineers use on every one of their reviews. What else have I missed? Let us know in the comments if you have a step that always finds mistakes for you!
