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.
I'm afraid it doesn't work like this. That would only be possible if the chip was using an FPGA fabric for the relevant parts of the design. For example if the L1 cache was implemented as an FPGA you could in theory patch around L1TF. But they wouldn't do that because it would be far slower/larger than implementing it directly as an ASIC.
Or you might imagine a chip that has an FPGA on the side (I expected Intel would ship this after acquiring Altera, but it never happened). But the FPGA would somehow have to have access to the paths that caused the vulnerability, which is highly unlikely, and would also be really slow compared to what they actually do which is hacking around it by microcode changes.
But I get the sense this part was aimed at a few very specific customers. It required some PCB-level power delivery changes, so you couldn't even drop it into a standard server motherboard.
FPGAs are too slow for that. I think you can get the clock rate up to about 600Mhz, but that is only for very small portions of the chip. Otherwise you run into timing issues. The clock speed for most of the chip will be significantly lower.
Yup. If you just want a CPU, use a CPU. an FPGA is a terrible substitute, and generally you only want to embed a CPU on them if you are either developing a CPU or you want a not very fast CPU as an addon to a design which is already using an FPGA (and generally for this nowadays the vendors make FPGAs whith a CPU on the same die, because it's so common and frees up quite a lot of the FPGA fabric and power budget).
That's the real nightmare. Now all of a sudden, you can program the CPU itself if you can access the update mechanism. CPUs being non-programmable is a feature as well as a bug.
