How is this legally handled considering amd owns x86-64 and Intel owns x86?
As long as it's not used in commercial settings, will they pretend not to see it while users are in a legally gray area?
replies(1):
Still a cool piece of tech though.
Still an impressive work.
Simple RISC softcores run at 200-400 MHz in modern parts. Couple this with custom softcore accelerators and you can get very performant designs. The biggest issue with deploying FPGAs however is that it's much harder to design for, especially dealing with hard blocks, like memory controllers and PCIe.
It'd be very interesting to compare this to RISC-V.
In theory, RISC-V should be at about the same performance as ARMv8 (note that Cortex-A9 is ARMv7): https://news.ycombinator.com/item?id=15343287
The other use case is sorta the same thing, but is as a normal CPU with a few custom extensions. Sometimes no manufacturer's product fits your needs well and ASICs are expensive (also difficult to change), so some companies just ship customized CPUs on FPGAs with whatever extensions they need.
Xilinx's Zynq chips (FPGA with an ARM core) have been very successful, which kinda demonstrates that this is an attractive combination.
A more down-to-earth example shipped with an Arrow FPGA dev kit I got: they took a software and ported MPG123 (mp3 decoding). They then profiled it and isolated a candidate for acceleration (some moderately wide integer operation). The result saved meaningful amount of CPU cycles and power. (The FPGA board was battery driven, which is still unusual).
The high-end SSD market has had a lot of FPGA-based products for years, and recently many of them are using any leftover gates to add user-accessible CPUs (or occasionally ML-focused compute resources). It turns out that there are quite a few uses for having a CPU extremely close to your massive pile of data, rather than having a relatively narrow PCIe link between the storage and the CPU. These SSD controllers are usually forced to use pretty large FPGAs in order to have a high enough pin count to manage several TB of flash, and it seems that they often have logic elements to spare.
GPUs are pretty well documented (relatively speaking), so they make a good case study. Generally special processors will handle FIFO pulling (so the part that reads the command lists), DMA engines, power management, video codecs, DRM key management, and some other miscellaneous pieces (like run this code on the GPU' on certain interrupts, instead of interrupting the CPU). And that's all in addition to the shader cores you normally think of as 'the GPU'.
In the past, I've used simple processor cores in FPGAs for motor control.