I've been out of the "expensive electronics workbench" space for about 15 years now, but this is tempting me to get back into it. It's like my fantasy version of those cheap Owon USB scopes.
I've been around this space as a hobbyist for some time.
There is great hardware for capturing signals; there is great software for processing signals. But getting the two things together will fully consume 99% of any effort to build something.
So you have a device that generates a fat datastream and you want to get it into a buffer for the CPU or GPU. Seems like something that should be a solved problem, right?
1-gigabit ethernet is not fast enough, but there is nothing open source that supports interfacing with faster devices.
The only usb3 solution that is remotely available and economical is the Cypress FX3 and it /SUCKS/
Thunderbolt has been so locked down you can't even learn how it effing works without signing NDAs. The Linux kernel source is your only resource; not that it matters since you can't order the parts anyway. I'm quite frankly amazed to see an "open" project using it; I imagine that it must be some kind of reference design from the FPGA vendor. But I'm encouraged that there is now at least one example where someone has a solution for actual high speed (~40gbps) data streaming to learn from.
This project appears to be using an Atrix-7 with PCIe interface and uses the Xilinx XDMA IP to do DMA. It appears to be using an off the shelf M.2 Thunderbolt enclosure, but the documentation does not say which one. There is an alternative XLite firmware which looks like it is attempting to provide an interface that does not use the XDMA IP. So I guess things are still not quite so good here. Can anyone identify the M.2/Thunderbolt interface being used here? It's conspicuously absent from any documentation.
I have to say, that looks seriously impressive and I'd buy it if I had the spare cash.
Also check out the Red Pitaya
Red Pitaya has the same problem almost every other board like it has: it is completely impossible for it to transport the full firehose of data to and from the computer. Since you absolutely must decimate the data to and from the ADCs and DACs, you will have to become an expert in doing DSP on FPGA, wrestling a huge state machine that implements some semblance of Ethernet, etc. You spend literally all of your effort to transform and transport the data before the software that you want to process it can even touch it. It's an absolutely stupid waste of time and effort.
Sadly no sigrok and pulseview support. See https://forum.redpitaya.com/viewtopic.php?t=22866
Here is another good thread about the Red Pitaya ("sobering") https://www.reddit.com/r/embedded/comments/y9oxqb/red_pitaya...