The History, Status, and Future of FPGAs

As a bit of a counterpoint:<p>One of my prior projects involved working with a lot of ex-FPGA developers. This is obviously a rather biased group of people, but I saw a lot of feedback around that was very negative about FPGAs.<p>One comment that&#x27;s telling is that since the 90s, FPGAs were seen as the obvious &quot;next big technology&quot; for HPC market... and then Nvidia came out and pushed CUDA hard, and now GPGPUs have cornered the market. FPGAs are still trying to make inroads (the article here mentions it), but the general sense I have is that success has not been forthcoming.<p>The issue with FPGAs is you start with a clock rate in the 100s of MHz (exact clock rate is dependent on how long the paths need to be), compared with a few GHz for GPUs and CPUs. Thus you need a 5× performance win from switching to an FPGA just to break even, and you probably need another 2× on top of that to motivate people going through the pain of FPGA programming. Nvidia made GPGPU work by being able to demonstrate meaningful performance gains to make the cost of rewriting code worth it; FPGAs have yet to do that.<p>Edit: It&#x27;s worth noting that the programming model of FPGAs has consistently been cited as the thing holding back FPGAs for the past 20 years. The success of GPGPU, despite the need to move to a different programming model to achieve gains there, and the inability of the FPGA community to furnish the necessary magic programming model suggests to me (and my FPGA-skeptic coworkers) that the programming model isn&#x27;t the actual issue preventing FPGAs from succeeding, but that FPGAs have structural issues (e.g., low clock speeds) that prevent their utility in wider market classes.

I am working right now on bare metal websockets implementation on Xilinx Series 7 FPGAs. Currently it’s ZynQ SoC, but final product will probably have Kintex 7 inside, so no Linux. The tools make me cry, no examples, application notes from 2014 with ancient libraries. I hope, vendors will fix tooling. But I see, Xilinx has released Vitis, so their scope is elsewhere, no interest in old crap. Using Git with Vivado is already enough pain. So I keep my text sources in Git and complete zipped projects as releases. Ouch!

I wonder if it is possible to add a (small) FPGA to a personal computer that could accelerate any specific software tasks (video&#x2F;audio encoding, ML algorithms, compression, extra FPU capabilities) <i>on user demand</i>.

Maybe you will find this article about Large-Scale Field-Programmable Analog Arrays [FPAAs] interesting as well: <a href="https:&#x2F;&#x2F;hasler.ece.gatech.edu&#x2F;FPAA_IEEEXPlore_2020.pdf" rel="nofollow">https:&#x2F;&#x2F;hasler.ece.gatech.edu&#x2F;FPAA_IEEEXPlore_2020.pdf</a>

FPGAs are good at <i>nothing</i> in the scale that can challenge non-configurable silicons...<p>They are good at a lot of things that are in a smaller scales. Like general prototyping&#x2F;testing&#x2F;simulation, telecom, special-purpose real-time computing etc.<p>The behind-scene logic is that FPGAs can never make things as flexible as software. And flexible software always offset the inefficiency in a non-configurable chips. Just comparing FPGAs and CPUs&#x2F;GPUs will never teach FPGAs vendors the reality, or they choose to ignore after all...

2 are the main challenges of the FPGA utilization:<p>- The first one is the FPGA programming. Now using OpenCL and HLS is much easier compared to VHDL&#x2F;verilog to design your own accelerators.<p>- The second one is the FPGA deployment and integration. Until now it was very difficult to integrate your design with applications, to scale-out efficiently and to share it among multiple threads&#x2F;users. The main reason was the lack of an OS_layer (or abstraction layer) that would enable to treat FPGAs as any other computing resource (CPU, GPU).<p>This is why at inaccel we developed a unique vendor-agnostic orchestrator for FPGAs. The orchestrator allows much easier integration, scaling and resource sharing of FPGAs.<p>That way we have managed to decouple the FPGA designer from the software developer. The FPGA designer creates the bitstream and the software developer just call the function that wants to accelerate. No need to define the bitstream file, no need to define the interface or the memory buffer allocation.<p>And the best part: It is vendor and platform agnostic. The FPGA designer creates multiple bitstream for different platform and the software developer couldn&#x27;t care less. The developer just call the function and the inaccel FPGA orchestrator magically configure the right FPGA for the right function.

<i>&gt; Intel, AMD, and many other companies use FPGAs to emulate their chips before manufacturing them.</i><p>Really? I&#x27;m assuming if this is true it can only be for tiny parts of the design, or they have some gigantic wafer-scale FPGA that they&#x27;re not telling anyone about :-) Anyway I thought they mainly used software emulation to verify their designs.

IMO the next big application for FPGAs is going to be to serve as a programmable DMA-engine of sorts. Have some a bunch of hard logic like ALUs and&#x2F;or IO&#x2F;s strewn about. Like for hw accelerated sql queries, malloc&#x2F;free, data-specific compressors and the like.

I wonder what would be the advantages of using an FPGA to <i>test</i> a CPU design - compared to relying on a (presumably more accurate) computer-based simulation. (I understand the reasons one might want to <i>implement</i> a CPU in an FPGA.)

The thing with FPGA is that companies when faced with cash and time crunch will opt to use a FPGA instead of designing ASICs. The tools suck but companies will hire someone that will do it. FPGA fit a very particular constraint and still solves very specific problems efficiently

The problem that FPGAs have is that they are only good for low-volume solutions that require flexibility and have no power constraints.<p>That&#x27;s a really narrow market. Telecom equipment and lab equipment, basically.<p>If I need volume, I need at least an ASIC. If I need to manage power, I need a full custom design.

This is really interesting. If a cpu hardware vulnerability like spectre could be repaired by patching an fpga on the SOC that would be incredible. That type of functionality would overtake the entire cloud market in about 3 days.

inaccel.com is making lots of steps to bring FPGA to 2020<p>Spark&#x2F;k8s integration Abstraction of popular cores Python APIS Serverless deployments Etc