Live data from Hacker News

Why Use an FPGA Instead of a CPU or GPU?

blog.esciencecenter.nl

21–30 of 130 posts

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

#21

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).

No, FPGAs are used in production. There are also plenty of flash-based FPGAs available.

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

#22

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.

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

#23

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).

No, they retain state. We used an Altera DE1 in school and it retained our burnt in program until erased or reprogrammed

Probably burned into an external EEPROM or flash, the FPGA fabric itself still has to be configured by some external means. It's pretty fast but on-the-fly reprogramming of the FPGA logic is still an issue where you want to very quickly switch the logic on the FPGA.

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

#24

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, testing, etc) where this makes sense.

And not all FPGAs loose state when powered down. For those that do, there's typically an easy way to hook up a little Flash chip and bootloader to reload the state automatically on reset. For those that don't have that option (EG, currently working with an ABB robot, Mecco laser, and Rockwell PLC which all contain FPGAs, only the Mecco can boot itself), you store state in battery-backed SRAM and just leave the RAM on at all times.

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

#26

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).

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.

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

#27

"Intel does offer an emulator, so testing for correctness does not require this long step, but determining and optimizing performance does require these overnight compile phases." After some experience with FPGAs, the emulation step is not enough to test for correctness. Most of the problems happen while synchronizing signals with inputs/outputs and with other weird timing problems, glitches and unintuitive behavior…

Funny how some people believe that brain simulations are relatively nearby, but we can't even simulate an FPGa well enough to trust the model.

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

#28
post #10

"Intel does offer an emulator, so testing for correctness does not require this long step, but determining and optimizing performance does require these overnight compile phases." After some experience with FPGAs, the emulation step is not enough to test for correctness. Most of the problems happen while synchronizing signals with inputs/outputs and with other weird timing problems, glitches and unintuitive behavior…

There are a number of real issues with the emulation approach even now. Firstly, emulation isn't accurate - if you do floating point math in your application it will give you different results (within the tolerances of the OpenCL spec) on FPGA vs. CPU. So you can't test for correctness in the emulator. A second more serious issue is that getting performance that justifies using an FPGA requires tuning very carefully…

> if you do floating point math in your application it will give you different results

That seems like a gross weakness in the emulator; floating point isn't actually nondeterministic!

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

#29

Earlier quoted context omitted.

No, they retain state. We used an Altera DE1 in school and it retained our burnt in program until erased or reprogrammed

Probably burned into an external EEPROM or flash, the FPGA fabric itself still has to be configured by some external means. It's pretty fast but on-the-fly reprogramming of the FPGA logic is still an issue where you want to very quickly switch the logic on the FPGA.

Most FPGAs I've seen go out of their way to allow you to reconfigure while it's running, you just have to jump through a few extra hoops and get down and dirty with the floor plan.

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

#30
"...programming FPGAs is still an order of magnitude more difficult than programming instruction based systems." True statement. If you're offloading computation from a CPU, profile your application first, and determine if the FPGA board's architecture will allow you to improve performance. Don't underestimate the cost of communicating data to/from the FPGA/CPU.
Post reply on HN