5 ms·

Actually, I think FPGAs are amazingly cheap compared to what it would cost you to fab a chip of similar specs. A leading-edge FPGA will get you near-leading ed

Actually, I think FPGAs are amazingly cheap compared to what it would cost you to fab a chip of similar specs. A leading-edge FPGA will get you near-leading edge DSPs, memory blocks, SerDes, etc. What you _don't_ get is the frequency of a custom part for the full design (this is the FPGA overhead). Simple RISC softcores run at 200-400 MHz in modern parts. Couple this with custom softcore accelerators and you can get very performant designs. The biggest issue with deploying FPGAs however is that it's much harder to design for, especially dealing with hard blocks, like memory controllers and PCIe.

andrewf 8y ago
Are there detailed writeups of people building these things into their systems? (Something like https://blog.cloudflare.com/building-fast-interpreters-in-rust/ https://blog.cloudflare.com/building-fast-interpreters-in-ru... but for FPGAs instead of Rust).
bogomipz 8y ago
>"Couple this with custom softcore accelerators and you can get very performant designs." Can you elaborate on what these softcore accelerators are or how they work? Might you have any links?
- FullyFunctional 8y ago
  I don't have good references handy where I am right now, but Hotchips a couple of years ago had many examples, including a Memcache accelerator. A more down-to-earth example shipped with an Arrow FPGA dev kit I got: they took a software and ported MPG123 (mp3 decoding). They then profiled it and isolated a candidate for acceleration (some moderately wide integer operation). The result saved meaningful amount of CPU cycles and power. (The FPGA board was battery driven, which is still unusual).
- monocasa 8y ago
  Most decent sized designs, hard or soft, have little processors embedded in them in addition to their core logic. It's an interesting space/time/ease of development trade-off between a special little processor, and doing the same work in just logic. GPUs are pretty well documented (relatively speaking), so they make a good case study. Generally special processors will handle FIFO pulling (so the part that reads the command lists), DMA engines, power management, video codecs, DRM key management, and some other miscellaneous pieces (like run this code on the GPU' on certain interrupts, instead of interrupting the CPU). And that's all in addition to the shader cores you normally think of as 'the GPU'. In the past, I've used simple processor cores in FPGAs for motor control.

andrewf 8y ago

Are there detailed writeups of people building these things into their systems? (Something like https://blog.cloudflare.com/building-fast-interpreters-in-rust/ https://blog.cloudflare.com/building-fast-interpreters-in-ru... but for FPGAs instead of Rust).

bogomipz 8y ago

>"Couple this with custom softcore accelerators and you can get very performant designs." Can you elaborate on what these softcore accelerators are or how they work? Might you have any links?

FullyFunctional 8y ago
I don't have good references handy where I am right now, but Hotchips a couple of years ago had many examples, including a Memcache accelerator. A more down-to-earth example shipped with an Arrow FPGA dev kit I got: they took a software and ported MPG123 (mp3 decoding). They then profiled it and isolated a candidate for acceleration (some moderately wide integer operation). The result saved meaningful amount of CPU cycles and power. (The FPGA board was battery driven, which is still unusual).
monocasa 8y ago
Most decent sized designs, hard or soft, have little processors embedded in them in addition to their core logic. It's an interesting space/time/ease of development trade-off between a special little processor, and doing the same work in just logic. GPUs are pretty well documented (relatively speaking), so they make a good case study. Generally special processors will handle FIFO pulling (so the part that reads the command lists), DMA engines, power management, video codecs, DRM key management, and some other miscellaneous pieces (like run this code on the GPU' on certain interrupts, instead of interrupting the CPU). And that's all in addition to the shader cores you normally think of as 'the GPU'. In the past, I've used simple processor cores in FPGAs for motor control.