We write a lot about FPGAs here at EEJournal, with good reason, and you might get the impression that they’re the right solution to every design problem. They’re not.
Here’s a checklist to help keep you in the right path to successful design when considering FPGAs as a design alternative:
- If you just need to blink an LED, use something else. Often, your first introduction to FPGA design is the blinking light project. In real life, some designs don’t need to do much more than blink an LED but it’s not a proper job for an FPGA. You can buy microcontrollers for pennies that can accomplish this task with far less hassle. It was once fashionable to use a 555 timer IC to blink LEDs. That was back in the 1970s just after Signetics announced the 555. In terms of part cost, it’s now cheaper to blink the LED with a microcontroller than a 555.
- If a microcontroller can do the job, use a microcontroller. The advantage of a microcontroller is that it’s already designed and tested. The hardware is already known to work. So if there’s a microcontroller, any microcontroller, with the right hardware configuration for your project, then use that instead of an FPGA.
- If a Raspberry Pi can do the job, use a Raspberry Pi. The Raspberry Pi organization has done the embedded community a huge favor by turning out a series of very capable and very cheap processor boards, ranging from the Raspberry Pi Zero – which you can get for as little as $5 – to a Raspberry Pi 4 – which can cost as much as $75. At the high end, you’re getting an embedded board with a quad, 64-bit processor and myriad interfaces including dual-band WiFi and a camera interface. There’s extensive community support for Raspberry Pi development as well. If you think a Raspberry Pi isn’t serious hardware, consider this: I recently had lunch with a friend. His company is making gas chromatography equipment. They use a Raspberry Pi 4 as a controller because it’s cheap, it does the job, and someone else has already designed and debugged the board. Be like my friend’s company, if you can.
- Don’t you have better uses for your time? Compiling a design for a large FPGA still takes hours, and achieving timing closure can take days or even weeks for a tricky, high-speed FPGA design. Don’t you have better uses for your time? If you pick an existing microcontroller or ASSP, all of that design closure stuff has already happened long ago.
- If power consumption is important, don’t use an FPGA. The FPGA vendors love to tout the low-power aspects of their parts. Careful! Ask them, “Compared to what?” Capable FPGAs, in general, are NOT low-power devices. Want proof? Take a look at the heat sinks on those FPGA boards. You don’t see many microcontrollers sporting heat sinks, or fan sinks for that matter. When FPGA vendors say their devices consume less power than CPUs or GPUs, they’re talking about devices that dissipate on the order of 100 watts. You want an actual low-power alternative? Choose something else.
- Don’t care about latency? If you don’t care whether your system’s latency is measured in nanoseconds or microseconds, then you don’t need an FPGA.
- If you don’t know Verilog or VHDL, don’t use an FPGA. Sure, the FPGA vendors are all trying to grow their market by creating bridge compilers that transform C and C++ code into Verilog or VHDL. These tools are like the automated language translation tools that transform English into Hungarian or Urdu. It’s amazing that these tools work at all, but there’s a lot of nuance lost in the translation. In the case of FPGAs, you need to think parallel to get the full advantage of an FPGA’s massive parallel hardware architecture. If you need to perform thousands of multiply/add operations in one clock cycle, you can with an FPGA. However, C and C++ are not formulated to allow you to express parallel operations easily because they’re designed to create object code for sequential machines – namely microprocessors.
- Want to write code in Python or some other slow-boat interpreted language? Don’t use an FPGA. Please don’t think you’re going to get any sort of bare-metal performance from an FPGA if you write your code in an interpreted language like Python. Interpreted languages are designed purely for ease of use and are inherently slow. Sure, Xilinx offers a Python-programmable board called Pynq. It’s a great learning tool. It’s just not a performance tool.
- If you’re pinching pennies, don’t use an FPGA. For some applications, performance rules over cost and power consumption. For other applications, pinching pennies is the prime goal. Including an FPGA on your bill of materials will not help to pinch pennies. In general, FPGAs cost a lot more than microcontrollers.
- If you don’t want a lot of power supplies on your board, don’t use an FPGA. For some strange reason, FPGAs need a lot of power supplies – for the core voltage, for I/O voltages, for memory and memory-backup power, and so on. If you look at an FPGA board, you’ll see a lot of on-board regulators to create all of these various voltages just to make the FPGA happy. Before it was bought by Intel, Altera actually bought a power-supply module company called Enpirion. That ought to tell you how important power supplies are to FPGAs. Enpirion makes very cool products, but power supplies are a means to an end for most design engineers and not the main design goal.
- If you know your design will go into high-volume manufacturing, don’t target an FPGA. High-volume products (think millions of units) are the domain of ASICs, or structured ASICs if you’re in some mid-volume gray area. It’s fine to prototype with FPGAs for such product designs, but you want to jump to a custom device as quickly as possible because FPGAs are off by an order of magnitude or more when it comes to the three “P”s: performance, power, and price.
If you’ve just run that gauntlet of reasons you should not use an FPGA and still think you should, then you probably should.
- If your computational performance requirements cannot be met by running software in a processor, then you should consider an FPGA as a design choice.
- If you need significant amounts of high-speed I/O in the form of Gigabit Ethernet or multiple multi-lane PCIe ports, then you should consider an FPGA as a design choice.
- If you need to perform significant amounts of high-speed DSP, FPGAs should be your first choice.
- If you already have proficiency in Verilog or VHDL, then you should not hesitate to consider FPGAs as a design choice.
Do you have any advice to add to these lists? If so, please feel free to dispense that advice in a comment below.
Postscript: So many experienced FPGA designers have weighed in on this article with special cases where these rules of thumb don’t apply, that I am compelled to quote Picasso: “Learn the rules like a pro, so you can break them like an artist.”
Postscript #2: If time to market is the most important factor for your project, then an FPGA will get you to the finish line first. So will an off-the-shelf pcb assembly that’s already tested and debugged.
Leave a Reply
You must be logged in to post a comment.