3 ms·

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 want

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.

bayindirh 6y ago
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.
- wtallis 6y ago
  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?
  - Traster 6y ago
    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.
    - mikepurvis 6y ago
      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.

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.

bayindirh 6y ago

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.

wtallis 6y ago
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?
- Traster 6y ago
  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.
  - mikepurvis 6y ago
    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.