This page is an Electronics Design Checklist. It was
originally obtained from a HP document. It has been
extensively adapted to suit my and hopefully other design
engineers requirements. Copy it and edit it as you
see fit. Some checks are done automatic with most schematic
and pcb layout software, but serve as reminders.
1. Use a suitable universal file name for schematics,
and backup the file. Consider how useful “new_powersupply.scm”
will look in a few years.
2. Title block completed on all schematic and other
3. Check pin numbers of all custom-generated parts.
Especially check the rotation direction on footprints,
considering surface mount and DIP can be confusing.
Pinout may vary between DIP and various SMD packages.
4. Check power and ground pins of devices. Check supply
voltages as well as supply types are used appropriately
(battery, switched, ref_1V ).
5. Check hidden power and ground connections – or don’t
1. Unused CMOS inputs should always be pulled up or
down. Consider logic pins not connected directly to
power or ground but use resistors for in-circuit testing
2. Spare connector and IC pins accessible on prototype
boards, just in case. Use resistors to tie them to ground
so connection points are available.
3. CMOS gates always operated by logic levels at the
rails to minimize current.
4. No outputs joined together except open collector
(collector or drain ORed).
5. Inputs have current limiting resistors to protect
against expected voltages.
6. Outputs have current limiting to protect against
shorts and can supply expected currents.
7. Logic circuits not loaded inappropriately (to non
8. Open collector outputs have on board pullups. Check
that output pullup voltage is not restricted unexpectedly
by internal clamp diodes to the power rail.
9. Minimize opamp loads, especially LM324 and LM358
outputs loaded lightly to prevent distortion as the
device switches to higher current mode. (< 50 microamps,
and provide DC load to common).
10. Ensure inputs of unused opamps are not left floating,
and the amplifier is configured appropriately (so it
11. Check time delays and slew rates of opamps used
12. Use current limiting resistors on opamp inputs always
13. Check common mode input voltage range on opamps.
It is not always rail to rail.
14. Check failure modes and effects of failed power
15. Devices with quasi-bidirectional ports must not
have pull down resistors attached – they can toggle
16. Use hard pulldowns to get a low (< 1 K), or add
stronger pullup resistor. Make sure inputs cannot be
driven by hard voltage.
17. Consider grounding any crystals used on the board
to proper ground to reduce EMI.
1. External connections filtered for RFI and expected
voltages. Use ferrite beads for VHF, 100 ohms and 1
nF for RS232 and appropriate values for other lines
or sensor inputs. No capacitors on amplifier outputs
unless isolated by appropriate series impedances.
2. External I/O lines have a defined state when unplugged
(pullup or pull down).
3. Make sure I/O devices can handle unknown outputs
(usually inputs with weak pullup to high) until the
reset is over.
4. Consider making all external digital inputs active
low. Outputs may be either polarity but consider startup.
5. Consider connectors where ground made first and breaks
last for hot pluggability. Phono plugs are an example.
1. Check setup, hold, and access times for data and
2. Check capacitance and fan out limits for bus.
3. Check the data sheet and notes for unfamiliar ICs.
Read the small print and also in between the lines.
4. Search for meta stable states such as a 2 gate latch
which can be set and reset at the same time with an
indeterminate result. Other causes are clocked circuits
with runt clock pulses (too short or too low), or slow
rise time clock pulses. The result may be loss of timing
due to non logic levels, delayed state change or inappropriate
states, causing system failure. ‘Slack’ timing available
on clock pulses is an issue in reducing the adverse
5. Search for timing races where glitches can be generated.
An example is where two signals on different inputs
of a gate change at almost the same time (1 – 100 ns).
The logic can generate brief glitches. An example is
with decoders like 74HC138 which have several inputs
changing close together and can generate a burst of
glitches. Some will be ‘runt pulses’. These are best
used in systems with a latch or gate to enable the output
when the data has settled.
6. A reset circuit may be required to reset devices
to an appropriate state at power up.
1. Power supply filtering adequate, so input does not
approach regulator dropout at lowest supply and full
2. Rectifier diodes always add reverse recovery spikes
that pass through regulators. These usually end up as
10 mV noise pulses at line rate. Filter them with inductors,
resistors and capacitors as required. Snubbers across
diodes may help reduce radiation.
3. Use mains transformers with electrostatic shields
for really low noise systems. Plugpacks will usually
4. Power supply reservoir should be adequate, providing
a holdup time at least 200 ms at full load and lowest
5. Device supply decoupling adequate (especially CPU,
memory devices). Consider adding series impedances for
6. Use power supply polarity reversal protection. This
also ensures regulator cannot be destroyed by shorted
input (battery leads).
7. Regulators have supply capacitors bigger than total
load capacitance for protection against reverse bias.
8. Sufficient stabilizing capacitance on low dropout
voltage regulator outputs.
9. Consider cascaded regulators can have high current
states. Check them by slowly reducing the power below
minimum system voltage (until the regulators drop out)
while monitoring the current.
10. Solenoids and other inductive devices can generate
destructive voltages. Absorption circuits may simply
dump the spike on the power supply. The power supply
may not absorb them if it is a lightly loaded series
regulator. Even large batteries may not absorb the spike
if it has enough energy. The inductive device needs
snubbers and reverse clamps directly across it, not
just across the switch device. The power supply may
need to be appropriately clamped. Consider cars have
up to 100 V spikes normally!
11. Check operating voltage range of overall system
(low battery condition).
12. Consider fuses carefully, keeping in mind they protect
from fires, and protect the supply, not the load.
13. Check any devices that power down are isolated from
devices that remain powered up. Use open collector or
tristate interface devices with hardware operated control
line as appropriate.
14. Estimate total worst case power supply current,
and check that circuit operation agrees.
1. Voltage ratings and polarities of components checked.
2. Check polarized coupling capacitors cannot get reverse
voltage. Eliminate polarized capacitors where possible.
3. Check if undervoltage and overvoltage protection
4. Use over rated tantalum capacitors for longer life.
5. Amplifiers checked for stability.
6. Oscillators checked for reliable startup and within
reset time of clocked systems like microprocessors.
7. Check heatsinking requirements for maximum power
dissipation and worst-case operating temperatures.
8. Allow a wide safety margin for resistor power dissipation
(< 1/3 rating). They can easily melt solder or char
9. Keep reverse base-emitter current/voltage on bipolar
transistors low (use diode clamps).
10. Check for voltage transients and high voltages on
FET gates. Clamp gates of FET circuits to keep within
ratings. Check that FETs biased at non digital levels
have “gate stoppers” to limit high frequency
response and prevent parasitic oscillation.
11. Protect collectors/drains from fast risetime pulses
that may cause inductance in leads and loads to generate
damaging high voltage spikes.
12. Consider signal rate-of-rise and fall for noise
13. Separate analog signals from noisy or digital signals.
14. Surge current magnitude through semiconductors within
Reset and Supervisory
1. Reset circuit designs must be reliable, both glitch-free
and consistent; tested with fast and slow power supply
rise and fall time. The capacitor type is inferior –
consider comparator types, but test them carefully for
low voltage behavior.
2. Check reset behavior when power supply cycles before
the circuit is fully operational.
3. Consider watchdog timer testing, disabling and diagnostics.
4. Monitor power supply operation during shutdown and
startup and supply on-off cycling.
Printed circuit board (PCB) checklist
1. Copyright notice on PCB in copper.
2. Date code on PCB in copper.
3. PCB ID number and layer number on each layer in copper.
4. Drill legend – what sizes are used?
5. Netlist check – automatic and manual. Look for nets
with single nodes or too many nodes.
6. Design rule check. A manual version can find problems
missed by automatic checks.
7. Check for dead-end traces.
8. Ensure schematic software did / did not separate
Vcc from Vdd, Vss from GND as needed.
1. When determining board size go for a larger board
within reason. This decreases time to layout or auto
route, populate, debug and maintain. Small size is cute
but not always needed.
2. Consider PCB manufacturing panel sizes when deciding
on PCB sizes. (Minimize wastage of PCB’s per panel).
Holes on layout are probably finished sizes, after plating.
3. Finished hole sizes are >=10 thou larger than
the lead, or larger spec dictated by automatic insertion
4. Pads >=15 thou larger than finished hole sizes.
5. Place thru hole components on 50 thou grid.
6. All components >= 0.2″ from edge of PCB.
7. Silk screen legend text weight >=10 thou.
8. Check layout rules with your pcb manufacturer.
1. Are mounting holes electrically isolated or grounded?
2. Allow proper mounting hole clearance for hardware.
Allow space around them for stand off mounts, washers,
3. All polarized components checked.
4. No acute inside angles in foil.
5. No traces within 20 thou of PCB edge.
6. Serial number blank on silk screen legend.
7. Thru hole drill tolerance noted.
8. Thru hole solder mask tolerance noted.
9. Thru hole route tolerance noted.
10. Thru hole silk screen legend tolerance noted.
11. Use ground planes where possible.
1. Mounting holes matched 1:1 with mating parts.
2. All polarized components point same way.
3. Use but ensure there is minimum component body spacing.
4. Clearance for IC extraction tools.
5. Clearance for IC sockets (especially for during
proto phase). Sufficient clearance for socketed ICs.
6. Sockets used on devices prone to damage (near I/O
7. CPU devices usually socketed to allow bus testing,
8. Visual references for automated assembly (future
9. Tooling holes for automated assembly (future auto
10. Tooling and mounting holes have internal plane clearance
to avoid multilayer shorts. (Expect the software to
look after this, but check it).
11. Ensure pin 1 interpretation and orientation consistent
among all connectors of a given type on the board.
12. All ICs have pin one marking visible when chip is
13. Standoffs on power resistors or other hot components.
14. Check power and ground connections to all ICs.
15. Check hole diameters for odd components: rectangular
pins, spring pins.
Tracks and EMI
1. Trace width sufficient for current carried, consider
trace heating especially on internal layers.
2. Thermal relief’s for internal power layers.
3. Clearance for high voltage traces.
4. Clearance and guards between noisy and quiet lines.
Noisy ones to note are the capacitors on negative rail
7661 chips, RS232 lines, digital lines and busses. Keep
noisy lines short.
5. Bypass capacitors located close to IC power pins.
Minimize loop areas of decoupling capacitors.
High frequency crystal cases should be flush to the
PCB and grounded so they don’t become an antenna.
6. Check for traces running under noisy or sensitive
7. Use guard tracks round high impedance and low noise
lines. Keep them short.
8. Component and trace keepout areas observed.
9. Digital and analog signal commons joined at only
10. Place I/O devices near where their signals leave
11. EMI and RFI filtering as close as possible to exit
and entry points of shielded areas, I/O connectors.
12. Provide multiple vias for high current and/or low
13. Consider ground loops and voltage drops on tracks
– ground ain’t ground.
1. Provide a ground test point, accessible and sized
for scope ground clip.
2. Potentiometers should increase controlled quantity
3. Check the orientation of all connectors using actual
4. Silkscreen text located to be readable when the board
5. No vias under metal-film resistors and similar poorly
6. Check for traces which may be susceptible to solder
1. Assembly notes for all special operations such as
glue, inductors, clamps, brackets.
2. Conformal coating, and masking for it.
3. Special static handling precautions required during
assembly and test.
4. Wire size checked.
5. Cable ties or lacing cord shown where needed.
6. Color of wires.
7. Voltage drop at maximum current with specified wire
for entire current path (eg. power and ground).
8. Cooling requirements addressed.
9. Control of flexing, vibration and shock.
1. Use modular design.
2. Have a version number and change it every time the
software is modified. Have a note at beginning of software
explaining what has been done in this version.
3. Revision (version) history noted for all changes
(at top of source code)
4. Loops checked for exit conditions.
5. Communications and other ‘wait’ timeouts checked.
6. All branches tested.
7. Check for event showers, where one event causes other
events (e.g. a resize in a resize can cause a paint
and a resize, which causes more, until the stack is
8. Check for event lockouts (code running in a loop
prevents events being detected).
9. Check for interrupt showers (where one event causes
10. Check stack size with maximum pushdown.
11. Avoid using the stack for variables if relevant,
due to the confusion in popping and pushing.
12. Use defined variables (‘option explicit’ in basic).
13. Avoid re-entrant code – it is too hard to debug
14. Check the scope of variables. Global variables and
constants are defined in a special include file or module
if possible. Others may have local scope within a subroutine
or function or a module. In Visual Basic, variables
defined in a form are private to that form. Global variables
are defines in a module (.BAS) file, and can be read
by forms too.
15. Check any need for static variables. An example
is a ‘first-time’ flag. Global variables are static,
as they are stored in memory somewhere. Local variables
are dynamic, as they are stored on the stack for the
time the procedure is running only. They are temporary.
16. Event driven code, like interrupts, can be executed
any time. If global variables are set by this code and
used in other processes it is possible for meta stable
states to exist. The variable may be changed by an event
elsewhere while it is being processed. Protect against
this by having copies, multiple reads compared to make
the copy, or proper handshake flags. An example is a
hardware real time clock. Copy the value and work with
the saved value, rather than reading the RTC itself
each step of a procedure.
17. Avoid multiple ‘IF’ statements – they are confusing
and hard to understand or test. Use case statements
instead, where appropriate.
18. Each process (subroutine, function) should be small
and simple to avoid misunderstanding. Consider more
than 25 lines of statements as ‘suspicious’.
19. Follow the concepts of structured programming, avoiding
‘spaghetti’ code that is difficult to understand.
20. Consider the differences between ‘for-next’, ‘while’,
21. CPU utilization measured, especially in critical
loops such as processing an ADC or signal processing
where real time response is needed.
22. Interrupt response time measured.
23. Interrupt execution time measured.
24. Naming conventions consistent and meaningful.
25. Adherence to coding style standards – others or
even you may have to debug it.
26. Build in debug aids for example a debug flag to
allow test files to be run to emulate I/O.
27. Power-up, power-down considerations.
28. Unused interrupt vectors trapped.
29. Unused ROM space loaded with trap or restart instructions.
30. Warm and cold reset differences.
31. ROM default, user setting, stored (non volatile)
user settings considered.
32. Nonvolatile memory corruption possibilities checked
during power-up, power-down, and program-gone-wild conditions.
33. Adequate comments and design notes in code. Explain
I/O, steps being taken in global terms, not in terms
of ‘load R8’. Have a software manual or topic in the
technical manual if additional notes required.
34. Check for FIFO and buffer overruns.
35. Check critical timer driver code, timer event driven
36. Check for odd address usage on 16/32 bit micros,
especially an odd stack pointer
37. Use a standard reminder flag and check for any flagged
statements in software.
Test and Maintenance
1. Test points on PCBs for critical circuits, hard to
2. Test pads on a regular grid for (future) in-circuit
or bed-of-nails functional testing.
3. Test and calibration procedure written before production
4. Special test arrangements and connectors for testing
– provide schematic and describe in test procedure.
5. Easy disassembly and reassembly
6. Fuses accessible and labeled
7. Self test mode – software has built in procedures
such as analogue and digital I/O commands to aid in
8. Spare parts available.
Event logging of exceptional conditions.
1. Thermal cycling excursions internal to components
and assemblies within acceptable limits.
2. Capacitors mounted below or away from heat-dissipating
devices such as transformers.
3. Consider test aids on board such as test signal source,
switches, pushbuttons and status LEDs on PCB or elsewhere.
4. Provide test routines in software so commissioning
is automated where possible. Examples are memory test,
activity LED, watchdog test and disable, I/O tests.
Others are battery backup, RTC, non-volatile memory,
special test cycles.
5. Defaults for switches and settings that make the
system work in some defined way.
6. Error messages to indicate what problems the software
Safety and Environment
1. Remember electronic failures are due to bad environment.
2. EMC addressed, but in some cases special consideration
required for emission or susceptibility – eg a data
logger to work on the deck of a vessel must have RADAR
3. Resistance and tolerance of entire unit to static
discharge via any path
4. Vibration tolerance of entire assembly and individual
5.Protection against liquids and foreign objects
6. Clear safety warnings in manual and wherever hazards
exist. Control these hazards.
7. Fuse and circuit breaker size and characteristics
8. Fuse sizes marked near fuse holder
9. Room to remove fuse without damaging other components
– warning to remove power.
10. Spare fuse storage
11. Shock hazards
12. Radiated energy warnings and shields
13. Applicable standards checked
This topic was developed for equipment intended for
in house use, not for sale to others. A system being
marketed would need further steps for EMC and other
compliance, contact info, parts lists, warranty and
On developers workstations, use readily located directories
for software, user manuals and other documentation.
They should be project oriented.
Use a paper file folder during project development phase.
There is still some stuff that isn’t on a computer.
Use the internal website for final project information
stored in systems knowledge base. This allows users
and Engineering staff to download their own manuals
and other information. Have a separate area for each
project. Use html files designed so relevant parts (e.g.
manuals, checklists) can be printed.
User Manual: how to use, specification, field problem
solving, operational checklists, tips and procedures.
Service manual: commissioning, calibration and test procedures,
design notes as appropriate.
Calibration sheet template in word processor format.
Used to enter test results.
Test and calibration results for QA documentation, accessed
from project area of web site or stored as paper file
and referenced from website.
Information that may be lost if individuals depart the
organization – both computer and physical paper files
properly archived (CDROM).
Software source code archived (CDROM), with zipped executable’s
or other target files linked from internal web site
(software area). This allows users to download and install
their own software.
Correct all errors found in schematics, layouts and
Get others to test the device, especially the end user.
Compare the original purpose and project definition
with the end results.
Test that the specification is met, especially key
items like accuracy, deployment, speed, operational
resources (battery and memory reserves).
Make sure users understand special needs and instructions,
and have been advised about hazards, where to get help,
Ensure that default conditions and configurations are
such that a system will work immediately the user turns
it on, or at least explain what to do next.
Ask users if they are satisfied.
Please rate this article: