I have a computer engineering degree and what you are saying about using FPGAs for general purpose computing was correct when I graduated 20 years ago. It was 10-100 times more correct a decade after that, and is another 10-100 times more correct today. So somewhere between 100 and 10,000 times more correct now than in the 90s. And between 1000 and 1,000,000 times more correct in 2029!

But we're still using the same 3 GHz (effectively single threaded) chips today as then. Sure, RAM frequency is higher, but so is latency. Computers today are closer to 10 times faster than computers of the 90s, not 10,000 times faster like they should be. Except for video cards, which really are 100 or 1000 times faster, because they break with the single-threaded model.

FPGAs would work great for general purpose computing, but we're still missing a proper language for programming them. VHDL/Verilog is more like assembly language than the functional language we would need to do it effectively.

I haven't really kept up on this because it's been too depressing, but here are some promising approaches:

https://github.com/dgrnbrg/piplin

https://catherineh.github.io/programming/2016/12/26/haskell-...

https://www.eetimes.com/document.asp?doc_id=%201329857&page_...

https://news.ycombinator.com/item?id=14546535

So we'd need:

* An HDL wrapper that guarantees that any hardware description downloaded to an FPGA won't short it out. [might already exist, but needs proven examples/unit tests of pathological edge cases]

* A Lisp to HDL compiler, preferably with optimization. [time-consuming, but not difficult]

* A high-level functional or vector or stream language (Clojure/Elixir/MATLAB/Erlang/Go) to Lisp transpiler. [somewhere between trivial and straightforward, might already exist]

* An example implementation of a CPU written in a functional/vector/stream language, probably MIPS [not difficult, just time consuming to convert an existing spec to code]

It would be good to keep the transistor count under 1 million (say 100,000 gates), and possibly start with an 8, 16 or 32 bit implementation and emulate 64 bit and higher operations in microcode. Most CPU gates are wasted on out-of-order execution and cache, which aren't as important in parallel and stream-based/DSP computing:

https://en.wikipedia.org/wiki/Transistor_count

When I graduated, I saw a brand new chip where 75% of the die was for cache, although I can't remember which model number it was. Chips today are probably worse, since their speed to transistor count ratio has mostly gone down.

It looks like FPGAs might have stopped reporting gate count since they've doubled down on the proprietary route. A Xilinx Virtex-7 2000T FPGA from 2011 had 6.8 billion transistors which could implement roughly 20 million ASIC gates:

https://www.eetimes.com/document.asp?doc_id=1316816

So 8 years later with Moore's law that should be 5 doublings (32 times), or roughly 200 billion transistors and 640 million ASIC gates on a 2019 FPGA. The article says it takes about 340 transistors to form a gate on an FPGA, which seems high to me. But conservatively, 640 million gates would allow us to put 6,400 of our 100,000 gate cores on one FPGA.

Maybe someone ambitious can figure out how much RAM could be allocated per core in a 2D grid, based on the total core count. I'd like at least 1 MB per core, but that might conservatively require something like 10 million gates, which might limit us to 64 cores in RAM alone:

https://www.quora.com/How-many-transistors-flip-flops-and-ga...

It’s unfortunate that there is so much hand waving around transistor, gate and logic cell count. But it looks like we could put something like 64, 640 or 6,400 cores on a single FPGA today depending on how much RAM we allocate per core, and if we had the right software. And this would be a true parallel computer, probably running between 100 MHz and 1 GHz. So we could play around with things like copy-on-write (COW), content-addressable memory and embarrassingly parallel computation in all the areas that today's computers are weak at (things like ray tracing, voxels, genetic programming, neural nets and so on) and at least see how classic (UNIX-style) programming compares with the bare-hands/burdensome languages like CUDA and OpenCL.

If an FPGA can do all that, then surely it could devote some of its gates to the kind of reprogrammable logic you mentioned (perhaps for video transcoding, bitcoin mining, emulating video game consoles, things of that nature).