Getting Started with FPGAs for Makers: iCE40, Verilog, and Open-Source Toolchains

Every microcontroller project on this site — ESP32, Arduino, Raspberry Pi — runs software on fixed silicon: the chip's logic gates are wired the way the manufacturer wired them, and your code just directs traffic through that fixed hardware, one instruction at a time. An FPGA (Field-Programmable Gate Array) is a different kind of chip entirely: it's an array of reconfigurable logic blocks that you wire together yourself, in parallel, so instead of writing code that runs sequentially you're describing hardware that all exists and operates simultaneously. That's a genuinely different way of thinking about a problem, and it's worth having in a maker's toolkit for the class of problems where microcontrollers hit a wall — precise, deterministic timing; massively parallel operations; or interfacing with buses too fast for a microcontroller to bit-bang.

Why an FPGA Instead of Just a Faster Microcontroller

An ESP32 running at 240MHz still executes instructions one at a time (per core), and anything timing-critical is at the mercy of interrupt latency, cache misses, and whatever the RTOS scheduler is doing. An FPGA has no instruction fetch/decode overhead at all — the logic you describe is physically implemented as gates, so a signal generated on one clock edge is genuinely simultaneous with every other signal generated on that same edge. That makes FPGAs the right tool for things like: generating many independent, precisely-timed PWM or clock signals at once, decoding several high-speed serial protocols in parallel, building a custom bus interface that doesn't exist as a peripheral on any microcontroller, or retro-computing projects that recreate an old CPU's actual logic rather than emulating it in software.

Why Start With the iCE40, Specifically

FPGA development has historically meant Xilinx or Intel/Altera tooling: multi-gigabyte proprietary IDEs, license servers, and a learning curve steep enough to discourage hobbyists before they've blinked an LED. Lattice's iCE40 family broke that pattern because it's fully supported by a completely open-source toolchain — Yosys for synthesis, nextpnr for place-and-route, and IceStorm for the bitstream tools — with no proprietary software, no license, and no account creation required anywhere in the flow. It's a small, low-power, genuinely cheap FPGA family, which makes it the practical entry point for a maker rather than an engineering-team FPGA.

BoardFPGANotes iCEBreakeriCE40UP5KPurpose-built for the open toolchain, PMOD headers, good docs, the most "made for this exact workflow" option Tang Nano 9KGowin GW1NR-9CVery cheap, HDMI output on-board, uses the (also open, newer) Yosys/apicula Gowin flow instead of IceStorm Alchitry CuiCE40HX8KMore logic cells than the iCEBreaker, Arduino-shield-style expansion, good for slightly larger designs

Installing the Toolchain

The full open FPGA toolchain is packaged as OSS CAD Suite, a single downloadable bundle containing Yosys, nextpnr, IceStorm, and the supporting Python tooling — grab the release for your OS from the YosysHQ GitHub, extract it, and source the included environment.sh (or run the Windows setup script) to get every tool on your PATH. There's no separate install for each component and no build-from-source step required unless you specifically want a bleeding-edge feature.

Your First Design: A Blinking LED, the FPGA Way

The FPGA equivalent of "blink" isn't a loop with a delay — it's a counter register clocked by the board's oscillator, with one bit of that counter wired to the LED. In Verilog, that's a module with a clock input, an always block that increments a counter on every rising clock edge, and an output assignment tying the LED to one of the counter's higher bits (so it toggles roughly once a second instead of every clock cycle). The build flow is: yosys synthesizes your Verilog into a gate-level netlist, nextpnr-ice40 places and routes that netlist onto the specific FPGA's physical logic cells according to a board-specific pin-constraint (PCF) file, and icepack converts the routed design into a bitstream file that iceprog flashes to the board over USB. Every one of those is a separate command-line tool chained together, usually wrapped in a Makefile once you've done it by hand a couple of times to understand what each stage actually does.

Thinking in Hardware, Not Code

The biggest mental shift coming from microcontroller programming is that Verilog (or VHDL, or the newer Amaranth Python-based HDL) doesn't execute top to bottom — every always block and every module instance exists and runs concurrently, all the time, the moment the bitstream is loaded. There's no "next line" the way there is in C. Signals update based on clock edges and combinational logic settling, not based on program order. It takes real projects, not just tutorials, before this stops feeling backwards — expect your first few designs to include bugs caused by accidentally describing sequential logic where you meant combinational, or vice versa.

Where FPGAs Fit Next to Your ESP32 and Pi Projects

FPGAs aren't a replacement for microcontrollers in most maker projects — they're a complement for the specific slice of a project that needs deterministic parallel timing. A common real pattern is an FPGA handling a timing-critical interface (reading a high-speed sensor bus, generating precise multi-channel PWM, decoding a video signal) and handing processed results to an ESP32 or Raspberry Pi over SPI or UART for the "normal" application logic, networking, and display work that a general-purpose CPU is genuinely better suited to.

Where to Go From a Blinking LED

• UART transmitter/receiver in pure Verilog — a genuinely useful next project that forces you to think in state machines.
• A simple VGA or DVI signal generator (the Tang Nano 9K's on-board HDMI makes this especially approachable) — pixel-clock-exact video timing is a textbook case for why FPGAs exist.
• Implementing a small classic CPU core (many open designs exist for 6502 or Z80-style cores) to genuinely understand what a "soft CPU" running inside an FPGA means.

The open iCE40/Yosys/nextpnr path removes the two biggest historical barriers to trying FPGAs — cost and toolchain friction — and leaves you with the real barrier, which is a different way of thinking about how logic works. That's worth encountering deliberately rather than avoiding, even if 90% of your future projects still end up running perfectly well on an ESP32.