FPGAs Are Misunderstood

FPGAs have been around for decades, but most people still don’t really understand them. They’ve never achieved wide adoption, not because they lack potential, but because the tools to program them are terrible. Both the languages and the development environments are archaic by modern standards, and software engineers despise using them.

Many have tried to make FPGAs more accessible by shoehorning them into other frameworks, creating C-style imperative languages or clunky visual block interfaces. These efforts generally fail because they miss what makes FPGAs different in the first place.

What Makes FPGAs Different

Unlike a standard processor, which executes instructions step-by-step, you program an FPGA on a per-clock-cycle basis. An FPGA offers the ability to achieve effectively perfect timing: zero jitter with nanosecond-level precision. It’s the ultimate tool for real-time performance.

Most engineers react to that capability with, “That’s neat, but nothing I do needs that kind of precision.” And in most cases, they’re right. Their applications don’t require such extreme accuracy. This is also where the misunderstanding begins.

In those applications, engineers often rely on an RTOS (or sometimes bare-metal code) to manage timing. The engineer really has two problems that need to be solved: the application logic and the timing required for that application to function. They must solve both problems simultaneously so the system works together perfectly. Doing that in software is hard. The solutions must be completely intertwined. It’s prone to subtle bugs, strange side effects, and elusive race conditions that seem to vanish whenever you try to debug them.

A Better Division of Labor

FPGAs can detangle this trap by separating timing from application logic. The FPGA can manage the peripherals; it can collect and send data at the perfect moment every time and simply signal the processor when it’s ready via an interrupt. This model is simpler, more predictable, and far less error-prone.

Peripherals in an FPGA are surprisingly easy to implement. A SPI bus, for example, can usually be written in five minutes. (It often takes longer to read the relevant section of the MCU datasheet than to write the HDL code.) The same goes for RS-232 and many other standard interfaces.

FPGAs also make systems more adaptable. Add a header with spare GPIO pins, and you can program the FPGA to handle additional peripherals or protocol variations without redesigning the board. Recently, I connected a device that appeared to use RS-232 but of course the device didn’t quite follow the spec. With an MCU, I would have needed a board respin. With an FPGA, I implemented a fix in about ten minutes.

Programming an FPGA is not hard. It’s just different and requires a very different mindset. The tools are bad, the languages are bad, and the documentation is worse. And right now, the only practical way to learn FPGA development is to work with someone who already knows it. Once you grasp the basic patterns, it is a tedious but straightforward process.

This becomes a self-reinforcing problem. FPGAs are typically used only when there’s no other choice – in high-end, high-complexity systems that demand unique timing or throughput. Because those projects are inherently difficult, people assume FPGA development itself is difficult. The FPGA companies continue to design products for extremely complex projects because that is what the customers are using it for, but FPGA designs do not need to be complex or hard to understand. The people who would really benefit just get no exposure to those advantages, however.

A Shortcut for Embedded Development

FPGAs can make development faster, cheaper, and less risky. They simplify timing, eliminate many race conditions, and allow you to patch hardware problems in logic rather than respinning boards. 

For businesses, that means FPGAs can act as a form of insurance, a flexible layer between hardware and software that absorbs design mistakes, protocol quirks, and late-breaking requirements. They can help teams meet deadlines, stay on budget, and bring reliable products to market faster.

FPGAs should be a standard part of the embedded toolkit, not a last resort when nothing else works. The technology is already powerful; what’s missing is understanding.