Hacker News Reader

Comment by adwn | Hacker News Reader

Speaking as someone who programs FPGAs for a living, they are good for three things (I'm simplifying a bit here):

* interfacing with digital electronics, implementing low-level protocols, and deterministic/real-time control systems

* emulating ASICs for verification

* speeding up a small subset of highly specialized algorithms

Of those, only the last one would apply in the context of this thread. However, caused by their structure and inherent tradeoffs, they are completely incapable of speeding up general purpose computation. As for specialized computation, if they heavily rely on floating-point ops, a GPU will nearly always be faster and cheaper.

View on HN

I think the new Stratix might well beat GPUs, not?

The Reduceron specifically tries to quickly perform application of lambda expressions that GHC will try to avoid generating in the first place. The Reduceron speeds things up using several memory banks etc. but it still does things that shouldn't be done at all and the overhead is there at least in area and power.

I think FPGAs are too expensive to be used for general purpose computing. If on top of the chip price you add the development time it's just not cost effective. A high-end FPGA will cost you thousands of dollars and you won't be able to easily convert software code to HDL. A very high end GPU will be cheaper and easier to develop for.

There are situations where a FPGA is better suited of course (very low latency real time signal processing for instance) but for general purpose computing FPGAs are not exactly ready for primetime IMO.

> I think the new Stratix might well beat GPUs, not?

Adding to what simias said, even an FPGA with built-in floating-point primitives can beat a GPU (in floating-point-heavy computations when the measure is performance/cost) only if the algorithm doesn't fit well onto the GPU architecture – for example, if you can make use of the highly flexible SRAM banks on the FPGA. I suppose there exist such workloads, but they're rare.

Also, keep in mind that no FPGA comes even close to the raw external memory bandwidth of modern GPUs.

Altera/Intel and Xilinx have FPGAs coming out this year with HBM which should make them competitive with existing GPU memory bandwidth.

Even #2 is questionable. I had a front row view of a company that made a chip very quickly and one way they were able to do it was to not bother emulating ASIC in FPGA. There are some very nice and open-source hardware development tools that basically obviate that need.

I'm just a curious hardware development newbie passing by but would you be willing to share the open-source development tools used? It would be really interesting to take a peek at something that was used to develop a chip very quickly. Most of the hardware stuff seems to be quite complicated and not all that open.

I'm not the original poster, but perhaps he's thinking of https://chisel.eecs.berkeley.edu/ I believe it can (or could?) generate C++ code which compiles into a program that simulates your design.

They wanted to use chisel for the whole stack, but that was impossible because of one of their engineers.

Check out verilator

Once you get to the point where you need ASIC emulation, there are no open-source tools that are up to the task.

You don't need emulation for simple stuff like Bitcoin miners or other small and/or highly regular chips. You use it if you develop a large SoC taking tens of millions of dollars to develop. It takes months after finishing your HDL code and before you get the first silicon from the fab, and you don't want to wait that long before you can start testing your custom software.

So, no, #2 isn't questionable, it's routine practice. In fact, the largest FPGAs by Xilinx and Altera are structured explicitly with that use case in mind.

Emulation via FPGA or dedicated HDL emulator (a special supercomputer designed for running Verilog/VHDL, very fast, very good, very expensive) is also essential for functional verification of things like CPUs.

For example booting linux and running a simple application can take many billions of cycles. You simply can't simulate that many you need something faster (You can simulate a few billion overnight with an appropriate server farm, but that's across many tests using many simulator instances).

Unless you're NVIDIA, Intel, AMD, or Qualcomm, Apple, Samsung (you get the idea) why would you ever want to build anything besides "small and/or highly regular chips"?

I think there's a lot of interest in designing "highly regular" chips. And it's definitely possible to go quite far with open source tools. I've seen a 16-core general purpose chip with full 64-bit IEEE FP, ALU, and memory instructions operating at 1 MHz (real speed) as a gate-level simulation on a desktop computer. This could potentially be "running linux" at a reasonable (if sluggish) speed.

> Unless you're NVIDIA, Intel, AMD, or Qualcomm, Apple, Samsung (you get the idea) why would you ever want to build anything besides "small and/or highly regular chips"?

What's your point? The ASIC emulation market exists, there are several companies that build and sell ASIC emulators, and Xilinx and Altera cater to that market with dedicated FPGA devices. I'm not sure why you're arguing here.

Reply on news.ycombinator.com