https://www.doc.ic.ac.uk/~wl/teachlocal/arch/papers/cacm19go...
And maybe this is/was a pipe dream - maybe there aren't enough people with the skills to have a "golden age of architecture". But MSFT was deploying FPGAs in the data center and there were certainly hopes and dreams this would become a big thing.
We run such oscillators as dummy payloads for thermal tests while we are waiting for the real firmware to be written.
When a CMOS switches, it essentially creates a very brief short circuit between VCC and GND. That's part of normal dynamic power consumption, it's expected and entirely accounted for.
But I don't know how these cloud FPGAs could enforce that you don't violate setup and hold times all over the place. When you screw up your crossings and accidentally have a little bit of metastability, that CMOS will switch back and forth a little bit, burn some power, and settle one way or the other.
Now if you intentionally go out of your way to keep one cell metastable as long as possible while the neighbors are cold, that's going to be one hell of a localized hotspot. I wouldn't be surprised if thermal protection can't kick in fast enough.
It's just kibitzing though, I'm not particularly inclined to try with my own hardware
That's in no small part because the industry & tools seem to be stuck decades in the past. They never had their "GCC moment". But there's also inherent complexity in working at a very low level, having to pay attention to all sorts of details all the time that can't easily be abstracted away.
There's the added constraint that FPGA code is also not portable without a lot of extra effort. You have to pick some specific FPGA you want to target, and it can be highly non-trivial to port it to a different one.
And if you do go through all that trouble, you find out that running your code on a cloud FPGAs turns out to be pretty damn expensive.
So in terms of perf per dollar invested, adding SIMD to your hot loop, or using a GPU as an accelerator may have a lower ceiling, but it's much much more bang for the buck and involves a whole lot less pain along the way.
Intel tried to get around this problem by having a common framework. So one compiler (based on clang) with multiple backends for their CPUs, FPGAs, and GPUs. But in practice it doesn't work. The architectures are too different.
You can certainly pencil out FPGA or ASIC systems that which would attain high levels of efficient parallelism if there wasn't memory bandwidth or latency limits but there are. If you want to do math that GPUs are good at, you use GPUs. Historically some FPGAs have let you allocate bits in smaller slices so if you only need 6 bit math you can have 6 bit math but GPUs are muscling in on that for AI applications.
FPGAs really are good at bitwise operations used in cryptography. They beat CPUs at code cracking and bitcoin mining but in turn they get beat by ASICs. However there is some number of units (say N=10,000) where the economics of the ASIC plus the higher performance will drive you to ASIC -- for Bitcoin mining or for the NSA's codebreaking cluster. You might prototype this system on an FPGA before you get masks made for an ASIC though.
For something like the F-35 where you have N=1000 or so, could care less about costs, and might need to reconfigure it for tomorrow's threats, the FPGA looks good.
One strange low N case is that of display controllers for retrocomputers. Like it or not a display controller has one heck of a parts count to make out of discrete parts and ASIC display controllers were key to the third generation of home computers which were made with N=100,000 or so. Things like
and are already expensive compared to the Raspberry Pi so they tend to use either a microcontroller or FPGA, the microcontroller tends to win because an ESP32 which costs a few buck is, amazingly, fast enough to drive a A/D converter at VGA rates or push enough bits for HDMI!
Rapid product development. Got a project that needs to ship in 6-9 months and will be on the market for less than two years in small volume? Thats where FPGAs go. Medical, test and measurement, military, video effects, telepresence, etc.
The problem (for Intel) is that you don't sell billions of dollars of FPGAs into a mass market this way.
First off, clock rates on an FPGA run at about a tenth that of CPUs, which means you need a 10× parallelism speedup just to break-even, which can be a pretty tall order, even for a lot of embarrassingly parallel problems.
(This one is probably a little bit garbled) My understanding is that the design of FPGAs is such that they're intrinsically worse at getting you FLOP/memory bandwidth number than other designs, which also gives you a cap on expected perf boosts.
The programming model is also famously bad. FPGAs are notorious for taking forever to compile--and the end result of waiting half an hour or more might simply be "oops, your kernel is too large." Also, to a degree, a lot of the benefits of FPGA are in being able to, say, do a 4-bit computation instead of having to waste the logic on a full 8-bits, which means your code also needs to be tailored quite heavily for an FPGA, which makes it less accessible for most programmers.