Live data from Hacker News

Why Use an FPGA Instead of a CPU or GPU?

blog.esciencecenter.nl

31–40 of 130 posts

Re: Why Use an FPGA Instead of a CPU or GPU?

#31
I doubt that programming efficiency is what's holding back FPGA's for general compute.

Why ? because we've seen decades of research in this area - so at least we have some tools(c for fpga isn't ideal, but still...), and a lot of the general mapping between what algorithms should be in FPGA.

And Amazon FPGA's instance exist for over a year.

So in that time, if there worth while services to offer with FPGA's, people would have offered them, or at least started. And sure programming complexity is a barrier. but entrepreneurs and VC's love competitive barriers. So where's all this VC funding going towards this area ? Where are all those startups ?

Re: Why Use an FPGA Instead of a CPU or GPU?

#32
I've always thought FPGAs would be perfect to have hardware backed video decoding/encoding that could adapt to new codecs (like vp9) while also being updatable for new performance improving discoveries.

It also seemed like it would go well with a generic radio subsystem, so you could compile hardware support for new wireless standards that come out after your hardware did (essentially an fpga sdr).

It seems like there could be lots of uses for being able to on demand enable hardware acceleration for certain tasks a program might need lots of.

Re: Why Use an FPGA Instead of a CPU or GPU?

#33

Aren't FPGA's used mostly to test/design a circuit that you would then go on to actually fabricate/build? I could be wrong but I thought FPGA's were stateless (meaning if they powered off/reboot you loose everything and have to set it up from scratch again).

That is incorrect, or at least inaccurate, on both counts. FPGAs are often used to test/design not a "circuit" but an ASIC (application-specific-integrated-circuit) that you will then go on to actually build. Or, if your application doesn't have volume to suppprt the ASIC engineering costs but can support the FPGA unit cost, you just leave it as an FPGA. There are millions of devices (industrial machines, research, t…

Absolutely. In the worlds I work in, FPGA has been standard practice for years and years. As of late, it's becoming more common to place the CPU there for cost reduction.

In addition, you get the opportunity to both update the part and/or to change it's behavior via (for instance) a user setting.

Re: Why Use an FPGA Instead of a CPU or GPU?

#34
Another FPGA sweet spot is analyzing TB/PB-scale databases. Netezza programmed FPGAs to uncompress, project, restrict (including NULLs), enforce isolation & visibility and check CRCs at disk scan rates (>200MB/sec). When touching a handful of columns from a 20-200 column table, CPUs spend most of their time stalled on cache line misses. FPGA-projecting just those few columns into memory enormously increases cache hit rates.

Re: Why Use an FPGA Instead of a CPU or GPU?

#35

Earlier quoted context omitted.

Yes and yes but new uses are emerging, it's like 3D printing: there's a crossover where the extra cost you pay for flexibility becomes too much to compete with hard wired logic despite the high initial cost.

To be fair, it's not new. People have been using FPGAs in that capacity for decades.

Very true, but mostly EEs and embedded SW/FW engineers. I think the SW tools, although still awful, are reaching the point where more SW-focused developers can take advantage of FPGA flexibility.

Which isn't to say every programmer shouldn't be forced to struggle through a Verilog or VHDL project - that'll put some hair on your chest and the fear of god into you. I'll see your async and raise you an "always @(posedge clk)"

Re: Why Use an FPGA Instead of a CPU or GPU?

#36

Another FPGA sweet spot is analyzing TB/PB-scale databases. Netezza programmed FPGAs to uncompress, project, restrict (including NULLs), enforce isolation & visibility and check CRCs at disk scan rates (>200MB/sec). When touching a handful of columns from a 20-200 column table, CPUs spend most of their time stalled on cache line misses. FPGA-projecting just those few columns into memory enormously increases cache hit…

Plain C code can readily scan at a couple GB/sec on an ordinary Intel core, and NVME drives can transfer 8 or 16GB/sec

Re: Why Use an FPGA Instead of a CPU or GPU?

#38
One interesting use case for FPGAs is where hardware qualification is very expensive, for instance for use in space. If a given FPGA is already space qualified, you just need to load new code onto it and you can skip the expensive qualification step for your new application. You can also consolidate functionality of multiple chips into that one qualified FPGA.

Re: Why Use an FPGA Instead of a CPU or GPU?

#39

Aren't FPGA's used mostly to test/design a circuit that you would then go on to actually fabricate/build? I could be wrong but I thought FPGA's were stateless (meaning if they powered off/reboot you loose everything and have to set it up from scratch again).

Some FPGAs have built in flash that they will automatically load a bitstream from upon boot. If they don't, they typically can load the bitstream from an external flash chip upon powering up, or even via a microcontroller that's interfacing with the flash chip.

This is exactly how the Mega Everdrive and similar retro flashcarts work. The "OS" loaded from SD card configures an FPGA inside the cartridge.

Re: Why Use an FPGA Instead of a CPU or GPU?

#40
One clarification on the comment about latency. FPGAs are typically clocked much slower than a modern CPU. Typically, they run somewhere in the low 100's of MHz, whereas an Intel CPU clocks in at around 3GHz last time I went to the Apple Store. With a typical x86 multiply instruction having a latency of about, say, 3 cycles, putting that workload on an FPGA would result in a ~10x slow-down!

The real benefit of an FPGA is that you get to decide what happens in any given cycle. So rather than being able to multiply two numbers in a single cycle like on x86, you could make your FPGA design do, say, 20 multiplications in a single cycle (space allowing). Which means that you can now multiply 20 numbers in 1/10th of the time it would take on x86. (In reality I think you have something like four execution units capable of perfoming parallel ALU operations per cycle, depending on the family.)

So the latency benefit of an FPGA comes from flexible, almost (almost) unbounded potential for parallelism in a given cycle, not clock frequency. Hardware has to be designed to exploit this potential, otherwise it's not going to see any improvement in latency.

Anyways, just something that is maybe obvious once you're told it, but isn't always mentioned in discussions like this. It certainly something that I didn't fully appreciate before getting involved in hardware design.

Post reply on HN