Schematic Reviews for Firmware Engineers

As a firmware engineer, you will often be tasked with schematic reviews by your harware team. Take this seriously and provide a thorough review. Once a board is built, correcting mistakes may be difficult or impossible without re-spinning the board. If you don't understand the circuitry, sit down with the designer and walk through the schematics.

During early stages of a product cycle, I spend significant time reviewing schematics and brainstorming with the hardware team. During later stages, when the design is more mature, I often only perform sanity checks to make sure the latest changes look OK from a firmware perspective.

Phillip's Schematic Review Checklist

  • Does the system architecture make sense? If not, ask!
    • Is there a block diagram of the system? If not - do I understand the design enough to create one?
      • Understanding the big picture will help you catch mistakes
    • Are nets named consistently across connectors / different sets of schematics?
    • Are power rails labelled consistently?
  • Voltage domains
    • 3.3V goes to 3.3V parts, 1.8V goes to 1.8V parts, etc.
    • Do different IO blocks in the SOC have different voltage domains?
    • Can we use 1.8V instead of 3.3V for SOC?
    • Are there ways to eliminate voltage level translator ICs?
      • Powering different SOC IO blocks with different voltages?
  • Pullups (busses)
    • Do all busses that usually require pullups have them? (e.g. I2C, SPI)
      • Internal pullups are often not sufficient for busses - I highly recommend external pullups for most designs
    • Are signals pulled up to the correct voltage source?
    • Are pullups correctly sized?
  • Pullups/Pulldowns (default states)
    • Will the IO be initialized correctly when the board boots up?
    • Some IO rails from the SOC or PMIC may initialize with a certain state prior to software control - make sure this is accounted for!
  • Pin Mapping / alternative settings
    • Are pins mapped correctly?
      • A terribly nice engineer will cross reference each part's datasheet
    • Is there going to be contention on a bus due to parts in different power states?
      • I have seen poorly implemented I2C ICs take down a whole bus if the device is powered off.
    • Is a special purpose pin (e.g. IRQ or SPI friendly) being used when a normal pin (e.g. input/output only) could be used instead?
    • Do MSB/LSB assignments for busses map correctly? e.g. is bit 0 LSB on both busses, or is translation needed?
    • Do you need to set any alternative settings in firmware to account for the pin mapping?
  • Connectors
    • Do both sides of a connector have the correct pinout?
      • This is the #1 cause of schematic issues that I have seen in my career. Take your time, make sure they match in number of pins and pinouts.
      • If they don't match, have a damn good explanation for why.
  • Hardware Optimizations
    • Is there anything being done in hardware that can be handled in software?
      • This can be hard to find, but a big win if you identify a source of optimization. This is why it's important to understand the design and what each piece is doing.
      • Example: Reducing pins/resistors by utilizing internal fusing options
    • Is there anything hardware is expecting of software that is more easily handled in hardware (or totally infeasible)?
  • Debug options (early designs, development boards)
    • Are signals that you might need to scope brought out to debug headers or test points?
    • Do you have the ability to perform power measurements on a per-rail basis?
    • 0-ohm resistors for debug / rework options
      • Useful in evaluating multiple design paths, or having an escape option if you need to rework something.
    • Can any debug options be safely removed from a FF design?
      • You can regain space and reduce cost by removing these features once you are confident in a design. Keep them around on a dev board in case the need for debug arises.

Think something should be added to the list? Let me know in the comments.