Hacker News Reader

Comment by phire | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com