Is that about right?
If even close, (3) is very interesting to me for a variety of reasons. Is my understanding correct that this is a reasonable use of FPGAs and that maybe now is a reasonable time to get into it?
The only real benefit of an FPGA for algorithms is when you're algorithm benefits from parallelization.
There is nothing intrinsically faster in programmable logic.
The point is that execution is truly concurrent, as long as you have space in the FPGA fabric, you can _almost_ do everything at the same time.
I say this as someone who has done a fair share of FPGA projects, it is very difficult to make the business case for an FPGA, if your problem can be solved with GPU programming on a COTS GPU.
Regardless of whatever you read, FPGA's do have a purpose but will most likely continue to only be used in niche/custom applications.
It probably depends what you're comparing to.
Yeah, since FPGAs essentially implement combinatorial logic, and hard CPUs are also implemented in combinatorial logic, you gain no benefit from directly "porting" the hard CPU to the FPGA.
But, if your hard CPU is a microcontroller that can only process say 8 bits at a time, but you really want to process say 256 bits at a time, it might be more efficient to use an FPGA to build a soft CPU whose architecture better matches your problem. In that case, you should be able to do more work per clock cycle with the FPGA.
That's arguably "increased parallelization", but what I'm talking about applies to sequential algorithms.
Of course, in that case, maybe you chose the wrong microcontroller. Maybe a full CPU would be a better choice, or maybe there's a DSP that can be adapted to the specific use case.
it is very difficult to make the business case for an FPGA, if your problem can be solved with GPU programming on a COTS GPU
Sure, that makes a lot of sense at the high end. I'm thinking of problems more in the embedded space, where FPGAs might be a bit more attractive.
1. (general) application reconfigurability where the benefits of SRAM performance, integrated hard IP, fabric real estate, and/or cycle-accurate RTL control cannot be easily replaced by other roughly asymptotic solutions;
2. (general) offloading massively/embarassingly parallel compute architectures where commodity GPGPUs are either physically incompatible and/or power-wise too inefficient;
3. (enterprise) overall volume/performance/budget/schedule objectives fall short of the sort needed to justify pushing a bespoke ASIC design through process pipeline.
Relatively speaking, "blazing fast implementations of algorithms" is possible iff the compute bottleneck can be effectively parallelized; I'm not certain what was meant by "hard to run otherwise".
To put this into perspective, reliably clocking a non-trivial FPGA application at 200 MHz is objectively hard in a way that hobbyist types outside of the professional domain can't seem to understand (or arrogantly dismiss). And yet for the right class of problems, such an application may have the potential to put a GPGPU clocked in the GHz to shame on both compute throughput and power consumption fronts.
1. https://ieeexplore.ieee.org/abstract/document/5747245 Implementation of pin point landing vision components in an FPGA system for NASA stuff