There's the possibility of a Xilinx Zynq with AMD x86 cores instead of the ARM cores in current Zynq versions, though I'm not sure that would really be interesting to anyone.

Beyond that, there's been research in the past that envisions using a FPGA fabric as an execution unit within the CPU itself: https://www.microsoft.com/en-us/research/project/emips/ Intel hasn't pursued such a thing but that doesn't mean AMD couldn't.

I think you'd have a hard time making a large FPGA actually part of a CPU die due to area. A peer on the memory bus ala CCIX on the other hand...

Have you ever thought of building your own processor or maybe just defining your own machine instructions? With eMIPS now you can.

Microcode strikes me as the natural way to define arbitrary instructions.

I'm not so sure that's something which is really feasible from a design point of view. Everything involving instructions in the CPU is extremely performance critical and cross-cutting, so designing an interface which allows custom instructions without utterly destroying performance seems like quite a feat. I've a feeling the memory interface is a much more natural place for any integration (this is how it works on any existing FPGA + CPU chips)

What I want is a small FPGA that is really close to each CPU core. I want to be able to send a query to it with about the same minimum latency as an L1 hit.

Basically, I want it to implement what are essentially custom CPU instructions.

Rather than implementing your full algorithm on a big FPGA over a PCIe link, you should be able to implement just the few custom specialized instructions that regular CPU is missing, while still utilizing the regular CPU resources.

How would OSs manage this security and process wise? I imagine its impossible to program an fpga fast enough to have it switch config for each process that wants it.

Why re-program? Extend the X86 ISA with a set of instructions for mailbox style programming (put, trigger, wait for flag/interrupt, get), then address the FPGA as a set of registers and flags.

Hide the registers or set a flag if the FPGA is not configured for it.

Moreover, put another configuration flag to FPGA part so that it either shows up a device or works as a set of registers.

It's easier said than done but, it's not impossible.

How would accessing the FPGA through registers instead of instruction opcodes do anything to address the issue of needing to ensure that the FPGA is currently configured to behave in the manner expected by the current process, as opposed to the FPGA still being configured to suit the process that was running before the last context switch?

The fundamental way that an FPGA works (more or less) is to program the configuration registers with values that then determine the routing. One thing you could do is have multiple sets of these configuration registers, at process start you allocate one configuration to that process and set it up, from that point onwards you when you despatch instructions to the functional unit you do it along with the process configuration. So one process could be using the FPGA as a custom hashing function and another could be using it for some funky video IP. I'm not saying it's a guaranteed win but I think there are technical solutions that you could experiment with.

Sounds workable, though you'd also need a way to save and restore any internal state, or else some way to mark off checkpoints where it is interruptible.

The other thing to note is that this only covers using the FPGA for compute. While that's the obvious use-case for an "FPGA in CPU" concept, in the real world, IO is a pretty important part of many non-cryptocurrency FPGA applications, whether you're just counting edges on some input like an encoder, providing a highly time-sensitive output signal, such as for an SDR, or implementing some custom serial protocol.

Sounds kinda like microcode

Intel has an fpga+xeon combo, but it's poorly designed and expensive.

I'm not fit to judge, but the 6138P with integrated Alter 10GX appears to connect to the main Xeon cores via a UPI2 link and dual PCIe x8 links. It exports an HSSI bus, whatever that is[1].

The thing is, I don't think AMD is going to have much of an advantage. Back when AMD64 was becoming a thing, a long time ago, there was a lot of excitement around HyperTransport (HTX), around an inter-processor bus that people could make interesting accelerators out of & connect fpgas with. It never... really went anywhere. It's still supposedly quite prevalent as the basis for AMD's modern Infinity Fabric, but AMD seems to have no interest, no energy to make Infinity Fabric or HyperTransport interesting to the world, anything beyond an implementation detail.

If AMD does want to start integrating FPGAs, they either need to go back 17 years & start pushing Infinity Fabric / HyperTransport, or they need some other plan to make the fpga useful. Perhaps CXL or CCIX or GenZ or just like they do now gobs of pcie is enough, is how an fpga can mesh with core complexes & peripherals, but wow AMD would be in a much better place to start integrating FPGAs if HTX has kept up steam.

[1] https://www.anandtech.com/show/12773/intel-shows-xeon-scalab...

I think the idea of configurable hdl modules could be very interesting. A game could load a physics core. Ssh could load a security core and so on. These could be updated similar to firmware or even could ship with the application. The only barrier right now is the long programming times.

Well and the whole story with multi-tasking is pretty interesting. Does one application get exclusive use, with the thing able to somehow cache its state on a context switch?

currently the PCIe card would need some kind of driver to be written on the OS to communicate with it.

There's SoC devices that have a soft processor on it that runs a linux kernel and can communicate with the FPGA.

Are many of those devices actually reprogramming the FPGA at runtime from the OS running on the soft processor, though?

My impression was that you tended to define pretty static blocks of functionality (you know, hash calculators for your bitcoin mining or whatever), and then just communicate to those from the OS using interrupts and a shared memory interface like any other peripheral.

On the Zynq family of devices, you can load bitstreams at runtime from Linux through a device file in /dev