How FPGAs work, and why you'll buy one (2013)

I remember this article. This is by _yosefk.

I love FPGAs. They're awesome for interacting at a low level with just about any kind of hardware, at nano-second-level latency.

But although I bought one, I don't think most people will end up buying one, unfortunately; the vast majority of the consumer stuff that we considered putting on FPGAs in the past (graphics rendering, heavy math) is solved six ways to Sunday by today's GPU. The FPGA also lacks an open-source (or even shared-source) toolchain, there's no way to perform resource sharing, they have code constraints that are physical limits, and so on.

Basically, FPGAs rock when used for chip design or for powering custom prototype or small batch hardware. But they fall into a really narrow portion of the market, because there are few cost-effective consumer-level solutions that make use of FPGAs.

A shame, really. They're super cool.

Just a shout-out about the Icestorm project which provides a complete open-source toolchain for Lattice's iCE40 FPGAs. It's mostly the work of one guy (Clifford Wolf): http://www.clifford.at/icestorm/.

It's worth noting that arachne-pnr (https://github.com/cseed/arachne-pnr) is written by a different person (Cotton Seed).

Two previous discussions with lots of comments.

(109 points, 331 days ago, 107 comments)

https://news.ycombinator.com/item?id=9388751

(379 points, 999 days ago, 152 comments)

https://news.ycombinator.com/item?id=5895672

There's an important caveat that this is missing: yes, FPGAs can do a whole bunch of multiply-accumulate operations at once, but each of those units really wants to carry out the same multiply-accumulate operation every clock cycle, with inputs coming from the same sources and outputs going to the same destinations. With DSPs you can trivially execute a completely different step of the computation every clock using the same multiplier, but on FPGAs you either have to set up all your own control logic to multiplex all the DSP units in and out at the right time or have one multiplier per stage in the computation and inevitably lose efficiency because the rate you're feeding data in is slower than the speed the FPGA can run at. And large FPGAs are relatively expensive and, well, big - the bottom-of-the-range Artix 7 with 45 multiply-accumulate slices (enough for one 45-stage computation without complex tricks) is $25 and the smallest package you can get it in is 1cm2.

The thing that really got me excited about FPGAs was working with the "HappyBoard" that was used for MIT's 6.270 robotics competition[1]: it's similar to an Arduino (AVR microcontroller with pin headers broken out and USB), but with most of its IO (sensors, motors) going through a Xilinx FPGA rather than directly connected to the ATMega128.

What that meant was that the AVR, which was relatively slow at 8MHz, was free to run all your logic (including multithreading!) while the FPGA handled most of the timing-critical things, like motor PWM and sensor decoding.

But the coolest part was that you could dynamically modify the IO if you needed different behavior. Instead of having to find, buy, and wire up a standalone quadrature decoder IC to count axle rotations, I just had to write some code [2] and suddenly the board has a high speed quadrature decoder (or several) built in!

The biggest roadblock is the toolchain though - even though [2] was a pretty simple change, it took a long time to download and install the Xilinx ISE tools, and they're not the easiest to use.

I would love to see a general purpose AVR+FPGA board with the FPGA toolchain neatly packaged the way Arduino/Wiring has done for AVR. Verilog has a somewhat steep learning curve, so you might want to hide that in some kind of module system, with basic library modules like PWM, edge counting, or quadrature decoding that can just be mapped to the pins you want. Maybe something building on top of Icestorm?

[1] http://spacecats.mit.edu/contestants/happyboard-manual.pdf

[2] https://github.com/sixtwoseventy/joyos/commit/44975ea9bc64e5...

To be frank after having experience with both FPGA and software development. If you can solve the problem in software, just do it.

The cost in time and complexity of solving a problem in hardware is almost always larger.

When writing software you gain a level of abstraction. You do not have to deal with getting a special hardware (the FPGA), mess with proprietary buggy tools, and all the nitty gritty stuff of proper reset, multiple clock domains, timing closure where each rebuild of your code might take multiple hours to close. And don't get me started with writing HDL-code.

I implemented an object tracker using a FPGA and a webcam and there were multiple hardware problems that needed to be handled such as buffering data in the sdram (design a sdram memory controller), research and implement image filters and debug why the camera image sometimes got corrupted (the connection cables were too long).

Almost all of these problems would have been gone by instead connecting an USB-webcam to my PC and utilize the openCV library.

FPGAs are awesome. They help solve problems that software is too slow to solve, but aren't large enough in scale for ASICs. They're also great for prototyping new chips before actually shelling out the hundreds of thousands of dollars NRE for a new ASIC design.

Here's a great stackexchange discussion on why and how FPGAs can outperform CPUs for certain tasks: http://electronics.stackexchange.com/questions/101472/how-ca...

In the projects where I use them in university I always found them quite hard to work with.

While the idea of programming them with VHDL or Verilog is quite straightforward, there were a lot of bumps in the road to getting a working design. Specialized tools which generate reports that go on for pages and pages (our team was completely unable to do something about the path of longest delay), complicated information about the clock, and having to work with vague documentation and intellectual property.

FPGA's are really nice when they work, but I feel like they are just too complicated for developers to get started with on their own, at the moment.

This is a nice intro but the author forgets another downside of FPGAs which is power consumption. The hard cores help, but in the limiting case you end up with an ASIC.