4 ms·

I could never stop wondering why is this not a norm yet. Why doesn't every computer have an FPGA.

imtringued 6y ago
Existing FPGA vendors made sure their products remained in a lucrative niche by maintaining full control over the development process for FPGA designs.
rcxdude 6y ago
Apart from the tooling woes others have mentioned (it's hard to get across how much FPGA tooling sucks compared to software tooling), FPGAs occupy a strange set of niches, but it's not clear how many are ones which would benefit the average PC or server. If you want raw memory bandwidth and FLOPs, a GPU is better (on speed, power, and price). If you want to evaluate complicated conditions and control flow, a CPU is better (in the same catagories). Because FPGAs are very power hungry and generally slower than the raw silicon, they only really give you more compute if what you want to compute is either far enough off the beaten path that some custom logic is much more efficient than the available instructions, and/or it benefits from a specific parallel datapath which doesn't easily fit on a GPU or CPU (GPUs being the best at embarrasingly parallel systems and modern CPUs being good at parallelising general purpose code reasonably well). In practice you see FPGAs mostly in two areas: specialised embedded applications which benefit from heavy custom I/O and/or some efficient specific DSP but don't have enough volume to justify an ASIC design, or in accelerators for simulating ASIC design.
stefan_ 6y ago
Because adding a layer of abstraction to silicon transistors makes for terrible performance and energy usage. Every other year or so someone "rediscovers" FPGA and thinks this niche architecture is poised for a total revolution of how computing works, think drag&drop hardware and super fast custom everything. It never happens and it will never happen because customization, much like premature optimization, is the root of all evil and also just.. see the first paragraph.
- andy_ppp 6y ago
  I just always assumed it didn't happen because as soon as anything useful comes along in the FPGA space someone will just add it in normal silicon?
RantyDave 6y ago
GPUs came in and spoiled the party. FPGA's are better for low latency applications though. 5G etc.
mhh__ 6y ago
Probably power, getting the data onto the FPGA, and utilising FPGA's being unlike software. I definitely want one but any common task worth having on an FPGA is probably common enough to justify either a GPU or actual silicon. Intel and AMD both have the IP to do it, and iPhones do have a Lattice chip on them apparently
- rowanG077 6y ago
  Once partial reconfiguration works and the FPGA can access main memory directly I see a lot of use cases. Imagine applications reconfiguring the FPGA in the blink of an eye to optimize their own algorithms.
  - rjsw 6y ago
    There have been PCI FPGA boards available for a long time that can access main memory, I had them in my desktop machines nearly 20 years ago.
    - mhh__ 6y ago
      Attacking a hypothetical poorly isolated on-chip FPGA seems like the mother of all exploits, thinking about it
      - rjsw 6y ago
        The boards that I have used could not reprogram the FPGA over the PCI bus.
        mhh__ 6y ago
        I was thinking aloud about the memory rather than the actual FPGA bitstream
      - rowanG077 6y ago
        Why? To make an FPGA do what you want you need to be able to reconfigure it. If you have reconfiguration capability you need to have remote code execution. And in that case you have already lost.
amelius 6y ago
My guess: because FPGAs are slow compared to mainstream desktop CPUs and only make sense if you have massive paralelism. But then you'd need a massive FPGA which would be crazy expensive, plus you'd need a good way to handle throughput. I could be totally wrong, though.
- atq2119 6y ago
  That, plus programming FPGA kind of sucks. The software tool chains are somewhere between 20 and 30 years behind the state of the art for software development. Also, FPGAs can't be reasonably context-switched. Flashing them takes a significant amount of time, so forget about time-multiplexing access to the FPGA among different applications.
  - m4rtink 6y ago
    I could imagine some sort of API based queuing - say you have 2 "slots" you can program stuff on so if you play 8 k video you can have on flashed to video decoder while the other one can speed up your kernel compilation. If you then want to also use FPGA accelerated denoising on some video you recently recorded, the OS will politely tell you to wait for one of the other apps using the available slots to terminate first.
    - amelius 6y ago
      Is there even any progress in OSes with respect to how they deal with tasks/processes on GPUs?
      - atq2119 6y ago
        Progress relative to what? Since applications do all their rendering via the GPU these days, desktop multi-tasking requires reasonably time-sliced access to the GPU. GPUs have proper memory protection these days (GPU-side page tables for each process). That's big progress over 10 years ago.
        6y ago

Existing FPGA vendors made sure their products remained in a lucrative niche by maintaining full control over the development process for FPGA designs.

rcxdude 6y ago

Apart from the tooling woes others have mentioned (it's hard to get across how much FPGA tooling sucks compared to software tooling), FPGAs occupy a strange set of niches, but it's not clear how many are ones which would benefit the average PC or server. If you want raw memory bandwidth and FLOPs, a GPU is better (on speed, power, and price). If you want to evaluate complicated conditions and control flow, a CPU is better (in the same catagories). Because FPGAs are very power hungry and generally slower than the raw silicon, they only really give you more compute if what you want to compute is either far enough off the beaten path that some custom logic is much more efficient than the available instructions, and/or it benefits from a specific parallel datapath which doesn't easily fit on a GPU or CPU (GPUs being the best at embarrasingly parallel systems and modern CPUs being good at parallelising general purpose code reasonably well). In practice you see FPGAs mostly in two areas: specialised embedded applications which benefit from heavy custom I/O and/or some efficient specific DSP but don't have enough volume to justify an ASIC design, or in accelerators for simulating ASIC design.

stefan_ 6y ago

Because adding a layer of abstraction to silicon transistors makes for terrible performance and energy usage. Every other year or so someone "rediscovers" FPGA and thinks this niche architecture is poised for a total revolution of how computing works, think drag&drop hardware and super fast custom everything. It never happens and it will never happen because customization, much like premature optimization, is the root of all evil and also just.. see the first paragraph.

andy_ppp 6y ago
I just always assumed it didn't happen because as soon as anything useful comes along in the FPGA space someone will just add it in normal silicon?

RantyDave 6y ago

GPUs came in and spoiled the party. FPGA's are better for low latency applications though. 5G etc.

mhh__ 6y ago

Probably power, getting the data onto the FPGA, and utilising FPGA's being unlike software. I definitely want one but any common task worth having on an FPGA is probably common enough to justify either a GPU or actual silicon. Intel and AMD both have the IP to do it, and iPhones do have a Lattice chip on them apparently

rowanG077 6y ago
Once partial reconfiguration works and the FPGA can access main memory directly I see a lot of use cases. Imagine applications reconfiguring the FPGA in the blink of an eye to optimize their own algorithms.
- rjsw 6y ago
  There have been PCI FPGA boards available for a long time that can access main memory, I had them in my desktop machines nearly 20 years ago.
  - mhh__ 6y ago
    Attacking a hypothetical poorly isolated on-chip FPGA seems like the mother of all exploits, thinking about it
    - rjsw 6y ago
      The boards that I have used could not reprogram the FPGA over the PCI bus.
      - mhh__ 6y ago
        I was thinking aloud about the memory rather than the actual FPGA bitstream
    - rowanG077 6y ago
      Why? To make an FPGA do what you want you need to be able to reconfigure it. If you have reconfiguration capability you need to have remote code execution. And in that case you have already lost.

amelius 6y ago

My guess: because FPGAs are slow compared to mainstream desktop CPUs and only make sense if you have massive paralelism. But then you'd need a massive FPGA which would be crazy expensive, plus you'd need a good way to handle throughput. I could be totally wrong, though.

atq2119 6y ago
That, plus programming FPGA kind of sucks. The software tool chains are somewhere between 20 and 30 years behind the state of the art for software development. Also, FPGAs can't be reasonably context-switched. Flashing them takes a significant amount of time, so forget about time-multiplexing access to the FPGA among different applications.
- m4rtink 6y ago
  I could imagine some sort of API based queuing - say you have 2 "slots" you can program stuff on so if you play 8 k video you can have on flashed to video decoder while the other one can speed up your kernel compilation. If you then want to also use FPGA accelerated denoising on some video you recently recorded, the OS will politely tell you to wait for one of the other apps using the available slots to terminate first.
  - amelius 6y ago
    Is there even any progress in OSes with respect to how they deal with tasks/processes on GPUs?
    - atq2119 6y ago
      Progress relative to what? Since applications do all their rendering via the GPU these days, desktop multi-tasking requires reasonably time-sliced access to the GPU. GPUs have proper memory protection these days (GPU-side page tables for each process). That's big progress over 10 years ago.
      - 6y ago