I think I may not have been clear enough. I think we can take it as a given that there will be some kind of high-speed interconnect between the CPU and the FPGA (as you say, PCIe or QPI or whatever). But this is not the I/O problem I'm worried about. What I'm wondering is how the FPGA gets its access to the outside world. Does everything have to go through the CPU (which would be slow) or would the FPGA be able to use it's own multi-gigabit transceivers to talk directly to I/O devices (like NICs or HMC or Flash).
I always imagined that the best use of FPGA's in systems like this would as an I/O coprocessor. If the only way to get to the FPGA is via the CPU, then most (all?) of the benefit is lost.
Although having taken a look at those slides, it would appear that the FPGA is given it's own PCIe bus connectivity to the outside world. That could be an interesting way to interact with the outside world.
The Arria 10 GX can do up to 16x 30Gbps transceivers and 96x 17Gbps transceivers - I can't imagine they'd turn off all of these, since that is the selling point.
The question is where are they broken out? If at all? A bunch will be used for the QPI/KPI interface, but how many will get broken out to play with in the real world? If the slides are correct, 8x will be broken out as PCIe so that's something I guess. But not very much. Which is kind of the point I'm making. FPGA's are great I/O processor devices, but if you can't access the I/O, then that use case is toast.
Infiniband as a connection technology would be interesting (to me), but Intel has been developing something called Omni-Path, which seem to be their version of a successor for it.
Kind of wondering if these will work with Intel's Omni-Path, and if so, what the shape of that makes things...
In theory, could be very interesting. Reality though, we get to find out. :)
