Open Hardware

There's a recurring complaint you hear from every software engineer who wanders into FPGA development: the toolchains are nightmarish. Fifteen-gigabyte proprietary installs that check your Ethernet MAC address before they'll run. Synthesis tools that produce non-deterministic outputs — literally different results from the same inputs because the optimization uses unseeded random search. Vendor lock-in so thorough that engineers spend decades memorizing the quirks of one specific version of one specific toolchain, because that's all they can do when the source code is a black box.¹

Against this backdrop, the open-source hardware movement isn't just a philosophical preference. It's a survival strategy.

The Toolchain Revolution

The turning point was Project IceStorm, which reverse-engineered the bitstream format for Lattice iCE40 FPGAs. For the first time, you could go from Verilog to a running FPGA design using entirely open-source tools: Yosys for synthesis, arachne-pnr (later nextpnr) for place-and-route, and IceStorm for bitstream generation. The full flow takes seconds where vendor tools take minutes. You can simulate with Verilator, which compiles your Verilog into C++ and runs fast enough to iterate like a software developer — critical when you're used to sub-second compile times and suddenly facing fifteen-minute synthesis runs.²

Project Trellis extended this to the larger Lattice ECP5, and Project X-Ray started cracking Xilinx 7-series parts. The ecosystem now includes formal verification via SymbiYosys, which uses SAT solvers to exhaustively prove properties of your design — something that was prohibitively expensive with commercial tools. One hobbyist built a bug-free RISC-V core without ever running a single simulation, using only formal verification to ensure correctness. Every instruction, every pipeline hazard, every corner case — proven mathematically in minutes rather than tested probabilistically over weeks.³

The speed difference matters more than it sounds. When synthesis takes three seconds instead of three minutes, you can iterate at software speed. When your testbench is C++ compiled by Verilator rather than Verilog interpreted by ModelSim, you can hook up SDL to see your VGA output in real time, or run a full boot sequence in seconds. This doesn't just save time — it changes what you're willing to try.

Building CPUs for Fun

The poster child of open-hardware accessibility is RISC-V, the open instruction set architecture. Because the ISA is freely available, anyone can implement a RISC-V core. And because FPGA toolchains are now open, they can synthesize and test it without paying anyone a dime. The result is an explosion of hobby CPU design.

You can fit a dual-core 32-bit RISC-V processor in about 1,000 FPGA lookup tables — that's a trivially small fraction of even a cheap iCE40 UP5K.⁴ VexRiscv, written in SpinalHDL (a Scala-based hardware description language), is configurable enough to go from a tiny embedded controller to a Linux-capable core by changing parameters. Charles Papon's design is used in Precursor, in LiteX SoCs, in hobbyist projects, and in commercial products. It exists because the barriers fell far enough that one talented person could build something that competes with commercial cores.

The HDL ecosystem itself has diversified beyond Verilog and VHDL. Chisel (Scala), SpinalHDL (also Scala), Migen/Amaranth (Python), and Silice (a custom language designed for FPGA algorithms) all generate Verilog or VHDL as intermediate output. They bring software engineering concepts — parametric types, code generation, unit testing — to hardware design. Whether this is an improvement or a tower of abstraction waiting to collapse depends on who you ask, but it's undeniably expanding who can participate.²

Precursor: Open Hardware as Security Argument

The most ambitious project in this space is bunnie Huang's Precursor, a pocket-sized secure communication device built on an FPGA instead of a conventional SoC. The argument is elegant: modern SoCs contain "dark matter" — disabled test circuits, undocumented debug ports, pre-boot firmware blobs — that even the chip designers don't fully understand. An FPGA has none of this. Every line of the hardware description is auditable. There's no hidden microcode, no fused-in secret key hierarchy that you have to trust a vendor about.⁵

Precursor's SoC is built with LiteX, the Python framework for assembling SoCs from modular components. A RISC-V core, USB controller, cryptographic accelerators for AES and Curve25519, audio I2S, keyboard scanner, SPI flash — all described in open code, automatically wired together by LiteX's bus arbitration logic. The whole system compiles with reproducible builds, and the CI generates fresh documentation on every commit. If a logic bug is found, it's patched with a firmware update rather than a chip recall.⁵

The most striking piece is the Plausibly Deniable Database (PDDB), a filesystem that makes even the existence of secret data difficult to prove. Instead of encrypted volumes (which leak metadata about how many volumes exist), the PDDB uses "Bases" — overlapping cryptographic namespaces that are unlocked by independent passwords. Applications see a unified view of dictionaries and key-value pairs; which entries are visible depends on which Bases are currently unlocked. The genius is that the lowest-effort API for developers is also the safest — you don't have to write PD-aware code, because the database handles the overlay transparently.⁶

The cost is real: an FPGA is perhaps 50x more expensive and 5-10x slower than a feature-equivalent fixed SoC. Precursor's CPU runs at a modest clock speed and its memory is measured in megabytes. But the argument isn't about performance — it's about the epistemological relationship between a user and their hardware. Can you know what your device is doing? With a conventional SoC, the honest answer is no. With an FPGA-based open design, you at least have the option.

The $3 Linux Computer

At the other end of the ambition spectrum, George Hilliard built a Linux computer in a business card form factor for under $3 per unit.⁷ An Allwinner F1C100s (a cost-optimized ARM SoC with integrated RAM), an 8MB flash chip, and a handful of passives — that's the entire BOM. It boots in six seconds, presents a USB flash drive with a resume and photography, and drops you into a shell with rogue, 2048, fortune, and MicroPython.

This project is less about the technical achievement (though getting U-Boot and a mainline Linux kernel running on an obscure, poorly-documented Chinese SoC is genuinely hard) and more about what it reveals about the economics of computing. The most expensive component is $1.42. The PCB costs $0.80. You can hand-solder it with a cheap reflow oven and a laser-cut stencil. The entire firmware builds with Buildroot. If you can source the F1C100s (which requires buying from Taobao), you can have a complete Linux system for less than the price of a coffee.

This is the same trajectory that made the demoscene possible — hardware getting cheap enough that constraints become creative rather than exclusionary. When a Linux computer costs $3, the question stops being "can I afford to build this?" and becomes "what can I build with this?" The answer, given enough creativity and enough familiarity with the full stack from silicon to userspace, turns out to be surprisingly much.

What Connects All This

The thread running through all of it — from open toolchains to hobby CPUs to the Precursor to the $3 business card — is the belief that understanding your hardware matters. The demoscene explored this from the creative side: constraints force you to understand the machine deeply, and that understanding yields techniques nobody planned for. Open hardware explores it from the engineering side: if you can read the source code for your CPU, you can verify it, modify it, formally prove its correctness, or strip it down to fit in 1,000 LUTs.

The closed-source hardware world operates on trust. You trust that the vendor's silicon does what the datasheet says. You trust that the errata covers all the bugs. You trust that the undocumented debug port won't be used against you. The open hardware world doesn't eliminate trust, but it moves the trust boundary. You still trust the FPGA vendor's silicon, but everything above that — the CPU, the peripherals, the cryptography, the firmware — is open for inspection.

Whether that matters depends on your threat model. For most people, it doesn't. For the people it does matter to — journalists, activists, anyone operating in an environment where devices get confiscated and inspected — the difference between "trust us" and "here's the source code" is the difference between faith and evidence.