DrDreams: it looks like a comment you made 41 days ago resulted in your account being disabled (see https://news.ycombinator.com/threads?id=DrDreams). I'm quoting this sibling comment here for readability by those who do not enable showdead, as it is relevant to the FPGA discussion.

DrDreams 29 minutes ago | link [dead]

Speaking as an embedded developer, I see a number of other embedded devs hobbying around with FPGAs. However, I very rarely see convincing use cases for FGPAs. This article seems to lean toward the belief many of my colleagues have, that FPGAs are right around the corner in terms of general usefulness. However, I disagree strongly. I find that they are highly-specialized devices.

Before reading the rest of my writing, consider that at this time, brilliant hardware designers are putting similar amounts of work into both general purpose CPUs and into FPGAs. However, CPUS are comprised of dense blocks of special-purpose silicon for common purposes, such as floating-point math. FPGAs always have to match that dense silicon through configurable silicon, which is less dense. Furthermore, the routing in CPUs is a known entity at manufacturing time. On FPGAs, the routing is highly variable and must be re-negotiated at nearly every compile cycle. That's a huge time sink, both in terms of build time and in predicting performance. Especially since those short routes that you get at the beginning of a project, typically end up being longer by the end of it. Nowadays, we are seeing more FPGAs with dedicated, pre-made hardware blocks inside of them, such as FPUs and even CPU cores. These have more of a chance of catching on for general purpose computing. Notice however, that on these devices, it's the general-purpose CPU dominating, leaving the FPGA as a configurable peripheral, subordinate to the dense, pre-designed silicon.

Although one may be able to match GPU performance with an FPGA, it's usually just not worth it. It will take dozens of hours of FPGA coding and simulation. Compiling and fitting and the rest of the FPGA dev chain is very time-consuming and resource-intensive, compared to the speed and elegance of gcc. Speaking of standard development practices, FPGA code is not nearly as portable as C. It often has special optimizations done for the sake of the device implemented. http://opencores.org has a number of more generic modules available, but still, FPGA code does not scale as well as C code. There are add-on packages that help write FPGA synthesis code - code synthesizers, but they make matters especially complicated. The syntax of Verilog and VHDL is not well-designed for scaling. Speaking of these languages, if you are used to languages written to be parsed easily, such as lisp, python, or even C and Java to some extent, you will be very appalled at the structure of Verilog and VHDL. There are many redundant entities, lots of excess verbiage and all kinds of special cases. It really has evolved very little since the days of the Programmed Array of Logic (PAL).

Another problem with FPGAs is the additional hardware on board needed to configure them. It's one more component or interface that is not needed when using CPUs. It's an additional software image to maintain, revision, store in source control, etc. FPGAs also often require more power supplies and better power supply conditioning than a regular CPU and often a separate clock crystal. They are high-maintenance.

FPGAs do shine though in a few specific instances: 1. When there is a particular, uncommon high-speed bus protocol you need to communicate with and can not buy pre-designed silicon for. This does not mean, e.g. USB. It means something like a non-standard digital camera interface or embedded graphic display. 2. Software Radio. 3. Obscure, but computationally-intensive algorithms like Bitcoin.

I hope my words have convinced some people to cool their lust for FPGAs, because I feel they're a bit of a dead-end or distraction for many who are attracted to the idea of "executing their algorithm extremely fast" or "becoming a chip designer." I have seen many students and professionals burn up hours and hours of their time getting something to run on an FPGA which could just as easily have been CPU-based. For example, one student implemented a large number of PWM oscillators on an FPGA where it would have been much simpler to use the debugged, verified, PWM peripherals on microcontrollers. Another guy I work with is intent on running CPU cores on FPGAs. This is an especially perverse use of the FPGA. Unless you've got some subset of the CPU which adds incredible value to the process, you're exchanging the the density of the VLSI/ASIC version of the chip for the flexible, less dense version on FPGA. This may be useful in rare situations, such as adding an out-of-order address generator to an existing core for speeding up an FFT, but it suffers an incredible performance and developer time hit to get to this point.