I spend a lot of time in parts of the Internet where hobbyist electrical engineers gather. There are a few questions that come up over and over again in these spaces. One of the most common is also one of the hardest to answer:
How do I design a circuit board?
The reason it's hard to answer is because not everyone asking it does so for the same reason. Some people simply want to understand the mechanics, and can be helped by something like Hackaday's "Creating a PCB in Everything" series. Others want a beginner project to work on to start developing their skills, in which case they might check out Digikey's introductory series of videos. But for the purposes of this article, I'm going to focus on people who, when they ask this question, are really asking:
How do I solve a problem using electronics?
This is Part 1 of a blog series which will seek to answer that question through a tour of one of my own projects - Blue Oni, an open source Gigabit Ethernet Network Interface Card. I will talk you through not only every design decision that I make, but more importantly the process of making those decisions. Hopefully at the end, you'll have a good understanding of how to approach solving your own problems using electronics.
A Rough Outline
Here's a (rough, subject to change) outline of what I intend to cover with this series. As the posts are written, I’ll update this outline to contain the actual titles as well as direct links to the posts themselves.
How to Design a PCB - This post
Defining Requirements - Defining success for your PCB project
Choosing a Technical Approach - Evaluating and selecting a technical strategy
Key Component Selection - Choosing the core components of your project
High-Level Design - Blocking out the project to guide you during schematic capture and layout
Component Creation - How to avoid spending hours (or days) creating components in your EDA tool
Schematic Capture - Finalizing the design and capturing it into a functional, readable schematic
Layout - How to avoid stressing about layout (and those areas where some stress may be a good idea)
Review - How to review your design yourself, and how to get other people to do it, too
Again, I reserve the right to adjust this outline as things go along. If there's something on here you're looking forward to, or something you'd really like to hear about that isn't present in this list, let me know! I'd love to hear about it.
Stop Reading Here
Honestly, you probably don't need to read the rest of this post. All that’s left is a description of my problem, and presumably you already know what your problem is. But if you're interested in how the Blue Oni project came to be, or just want a bit more context on it, feel free to read on. Otherwise, just skip to the conclusion - I promise I won't be offended.
Step Zero: The Problem
Before anything else, you need a problem to solve. Your problem will be your own, but here's the problem which led to the Blue Oni project.
"As long as it's unobservable, firmware is the enemy. We need open firmware. I don't know if we're ever going to get there." -Bryan Cantrill, CTO @ Joyent
I very much enjoyed Bryan Cantrill's talk at Uptime 2017, "Zebras All the Way Down". In it, Cantrill discusses the problems caused by firmware bugs at Joyent's datacenters. This talk inspired me to think about where we could attack the problem of closed-source firmware. But before that, let's back up a step and ask ourselves:
What is the real pain here?
In this case, Cantrill's actual problem is that software further up the stack is failing in bizarre and novel ways. However, this failure is the result of many more failures (of both technology and process) at many levels. In order to enumerate some of these additional failures, I find it helpful to use the popular Five "Why"s technique. Cantrill starts us off:
The software is failing in bizarre ways
Because it's encountering conditions that are supposed to be impossible.
Because the hardware is misbehaving and not honoring its contracts with the software
We don't know why
Because the problems are occurring in firmware and we can't observe the firmware
Because the firmware doesn't have good monitoring, it's closed source, and we can't replace it
However, I find that five is sometimes not enough "Why"s to get to a true root cause. Let's go a bit deeper:
Because the firmware runs on proprietary microcontrollers and ASICs
Because those are the parts designed into the various system components
Because only those parts provide the features, performance, and cost which make the components feasible
Now we have ourselves a nice deep tree of problems, and we can start discussing ways to solve them and whether a solution at that level will solve our original pain point.
I'll skip a lengthy deliberation here because I'm not actually Cantrill and I don't work for Joyent, or indeed for any large datacenter provider. I chose the bottom three problems to tackle because, frankly, they sounded like the most fun! Thus Blue Oni aims to implement a NIC which does not use proprietary ASICs, but which nonetheless delivers a useful set of features at an acceptable performance and cost.
Next Time: Defining Requirements
Thanks for reading! The next post in this series will explain how to derive technical and business requirements (in other words, define success) for your PCB project. After that, we'll get into the technical nitty-gritty and talk about choosing a broad technical approach to the problem. For the more business-minded, I'll also talk a little bit about how to determine whether a PCB is even a good solution to your problem, and if it is, whether it's worth your time to develop it yourself.