I spoke w/ Chris a while back on Amp Hour about design review checklist best practices. Well, we recently added a feature to AllSpice which auto-populates a checklist for new design reviews. As part of that I’ve added a demo checklist people can fork to get started. I spent a good amount of time compiling this list from various sources, and adding some of my own best practices.
I made it all markdown compatible, so if people find it useful, feel free to use it (click “Raw” to get the source). I just ask that you link back to us and submit any improvements you make.
The idea is that this should really cover only common issues and minimize the number of words (any details should be linked to externally. For example, if someone has best-practices for part naming link to an external page with those specs).
Did I miss any big subjects? Anything I included that I should get rid of?
I also saw this CE thread, so I’ll read through and see if I can find any good items to add.
I love this checklist! Definitely going to adopt it.
I have my own “don’t make that mistake again” pre-release checklist. You’ve covered the majority of things on it, but here are some as well:
Make sure the project has a clean BOM with accurate part numbers for everything in it.
Check that any optoelectronics, or any other parts that might have weird reflow requirements, are thusly noted in the fab drawing (we had a bunch of boards recently where the LEDs required a particular profile, and neither we nor the CM noticed that it might be a problem before baking them all to death)
Make sure any and all flat flex/FPC connector pinouts line up with the mating cable, top/bottom contact connectors are specified correctly, and same/opposite side cables are specified correctly. Use paper to do it.
On ground planes, pour any pours you’re going to make, and thoroughly stitch them to avoid resonant structures. I usually do this last so I can manually optimize stitching vias on thin sections/between tracks/in corners/etc.
Add a picket fence to GND if you are going to.
Verify that your tool is set up with the correct design rules for your vendor (you should have done this at the very beginning, but it’s always possible you didn’t, or changed vendors somewhere in the middle and most things are “close enough” but some are off.
DRC actually passes
I have a handful of checks for “stuff that should be included in the manufacturing package” as well, but it can be a little tool-dependent.
Yes, but how do you know you are using the checklist correctly!! You can easily skip a step and miss a crucial step!
You have to use the circle-x procedure on your checklists. Without it, your checklists are useless. Better, someone watches you perform the circle-x procedure on the checklist to make sure you are circle-x-ing correctly.
I have spent much time circling steps and X’ing them off. I’ve spent more time watching people circling steps and X’ing them off. It’s the only way to ensure completeness.
One thing that’s useful in design level checklists is to have a “no change from prior design” checklist item.
Hey Nash! Yeah, I think that’s a great idea. I might add a suggestion in the comments. I think the best practice would be to mark the line item with a strikethrough and a note to communicate you’re skipping it, like:
~[ ] Review PCB outline~ [No change]
^ should render as a strikethrough in markdown
You have to use the circle-x procedure on your checklists
@jbdatko I like this idea. I think similar to above, maybe bold and WIP note would be helpful for the bigger tasks so that no one does double-duty. If you’re using Jira/GitHub/AllSpice you could also @tag someone in the checklist item to ask for a review on a particular item.
Checklists can get a bit crazy if they try to cover everything
@dale Yeah, it’s tough to hit that balance. One nice thing about having in a simple markdown text (as opposed to HTML web form) is that users can strike out or delete sections where are obviously not relevant (like PCB for schematic-only modifications).
Here’s one based on an article in EDN magazine
Ha, this checklist is a bit more morbid than I was expecting
Maybe the wrong url??
I have my own “don’t make that mistake again”
@alexw Oh yes, this is great - I knew I could find some folks here that were keeping their own lists. You are much more diligent than I am while doing designs. Will add these for sure.
Good call on temperature profile’s! I have also melted some plastic LEDs in the past. And the Flat Flex note… I’m getting PTSD reading through your list
Actually my checklisting also comes from a former boss. My self-documentation as well. His position was always that the documentation and notes should be straightforward and thorough enough that if he died tomorrow, it’d be a minor hiccup for continuity. The secondary reason being that he’d never remember anything well enough to replicate it exactly, and he ALWAYS needed to reference prior work at least once.
@kdumont I sincerely regret linking to the wrong document! Sorry sorry sorry! And my sincere apologies to anyone else I offended (to those that didn’t see the original, I had accidently linked to a “dearly departed” checklist from a wills kit).
Instead of linking this time I’m attaching the intended checklist. It was originally shared by Hank Wallace, writing for Electronics Design, and as I said before, the detail gets a bit crazy. However even though it’s over 20 years old pretty much everything is still relevent. Hardware Design Checklist.doc.pdf (99.6 KB)
