December 8, 2022
  • December 8, 2022
  • Home
  • Hardware stuff
  • 11 Reasons You Should NOT Use an FPGA for a Design, & Four Reasons You Should – EEJournal

11 Reasons You Should NOT Use an FPGA for a Design, & Four Reasons You Should – EEJournal

By on September 20, 2021 0


[ad_1]

September 20, 2021

11 reasons why you should NOT use an FPGA for a design, and four reasons why you should

“I guess it’s tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” – Abraham Maslow

by Steven Leibson

We write a lot about FPGAs here at EEJournal, for good reason, and you might feel like they’re the right solution for every design problem. They are not.

Here is a checklist to help you stay on track to successful design when considering FPGAs as a design alternative:

  1. If you just need to flash an LED, use something else. Often times your first introduction to FPGA design is the flashing light project. In real life, some designs don’t need to do much more than flash an LED, but that’s not appropriate work for an FPGA. You can buy microcontrollers for pennies which can accomplish this task with much less hassle. It was once fashionable to use a 555 timer IC to flash the LEDs. This was in the 1970s right after Signetics announced the 555. In terms of the cost of parts, it is now cheaper to flash the LED with a microcontroller than a 555.
  2. If a microcontroller can do the job, use a microcontroller. The advantage of a microcontroller is that it is already designed and tested. The hardware is already known to work. So if there is a microcontroller, any microcontroller, with the right hardware configuration for your project, use that instead of an FPGA.
  3. If a Raspberry Pi can do the job, use a Raspberry Pi. The Raspberry Pi organization has done a huge service to the on-board community by producing a series of high-performance and very inexpensive 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 up to $ 75. In the high end, you get an on-board card with a 64-bit quad processor and a myriad of interfaces, including dual-band WiFi and a camera interface. There is also extensive community support for Raspberry Pi development. If you think a Raspberry Pi isn’t serious hardware, consider this: I recently had lunch with a friend. His company manufactures gas chromatography equipment. They use a Raspberry Pi 4 as a controller because it’s cheap, it gets the job done, and someone else has already designed and debugged the board. Be like my friend’s company if you can.
  4. Don’t you have better uses of your time? Compiling a design for a large FPGA still takes hours, and achieving the time shutdown can take days or even weeks for a delicate high-speed FPGA design. Don’t you have better uses of your time? If you choose an existing microcontroller or ASSP, all of that design closure work has already happened a long time ago.
  5. If the power consumption is high, do not use an FPGA. FPGA vendors love to tout the low power aspects of their components. Careful! Ask them, “In relation to what? »Capable FPGAs, in general, are NOT low power devices. Do you want proof ? Take a look at the heat sinks on these FPGA boards. You don’t see a lot of microcontrollers that have heat sinks or fans for that matter. When FPGA vendors say their devices use less power than CPUs or GPUs, they’re talking about devices that dissipate in the order of 100 watts. Want a real low-consumption alternative? Choose something else.
  6. Don’t care about latency? If you don’t care whether your system’s latency is measured in nanoseconds or microseconds, you don’t need an FPGA.
  7. If you are new to Verilog or VHDL, do not use an FPGA. Of course, FPGA vendors are all trying to grow their market by creating bridge compilers that turn C and C ++ code into Verilog or VHDL. These tools are like the machine translation tools that turn English into Hungarian or Urdu. It’s amazing that these tools work, but there are a lot of nuances lost in the translation. In the case of FPGAs, you have to think in parallel to take full advantage of the massive parallel hardware architecture of an FPGA. If you need to do thousands of multiply / add operations in a clock cycle, you can do it with an FPGA. However, C and C ++ are not formulated to allow you to easily express parallel operations because they are designed to create object code for sequential machines, namely microprocessors.
  8. Want to write code in Python or some other slow interpreted language? Do not use an FPGA. Please don’t think that you will get bare metal performance from an FPGA if you write your code in an interpreted language like Python. Interpreted languages ​​are designed only for ease of use and are inherently slow. Of course, Xilinx offers a Python programmable card called Pynq. It is a great learning tool. It’s just not a performance tool.
  9. If you’re pinching pennies, don’t use an FPGA. For some applications, the performance rules on cost and energy consumption. For other applications, pinching a few cents is the main goal. Including an FPGA on your BOM won’t help waste pennies. In general, FPGAs cost much more than microcontrollers.
  10. 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 – for core voltage, for I / O voltages, for memory and memory backup power, etc. If you look at an FPGA board, you’ll see a lot of on-board regulators creating all of these different voltages just to make the FPGA happy. Before being acquired by Intel, Altera actually bought a power module company called Enpirion. This should tell you how important power supplies are for FPGAs. Enpirion makes some really cool products, but power supplies are a means for most design engineers and not the primary focus of design.
  11. If you know your design will be for high volume manufacturing, don’t target an FPGA. Large volume products (think millions of units) are the realm of ASICs, or structured ASICs if you find yourself in a mid-volume gray area. It’s fine to prototype with FPGAs for such product designs, but you want to switch to a custom device as quickly as possible because FPGAs are out of step an order of magnitude or more when it comes to the three Ps. : performance, power, and price.

If you’ve just run into this glove of reasons why you shouldn’t be using an FPGA and still think you should, then you probably should.

  1. If your computational performance requirements cannot be met by running software in a processor, then you should consider an FPGA as a design choice.
  2. If you need significant amounts of high-speed I / O in the form of Gigabit Ethernet or multiple multichannel PCIe ports, you should consider an FPGA as a design choice.
  3. If you need to do significant amounts of high speed DSP, FPGAs should be your first choice.
  4. If you are already familiar with Verilog or VHDL, feel free to consider FPGAs as a design choice.

Do you have any tips to add to these lists? If so, feel free to give that advice in a comment below.

[ad_2]