Streaming data FPGA interface -> off the shelf? - Page 1
Forum section: electronics / general

author: drwho9437
author_rank: Regular Contributor
timestamp: January 08, 2022, 09:40:05 pm
content: I am looking for good solutions to provide steaming data back to a computer from a digital system.I am aware of Opal Kelly's offerings, but feel the value proposition for me isn't that great. I don't need a big FPGA or lots of memory really and of course they realize the value of their software and charge a reasonable industrial rate for their stuff. At work that is fine but not for home stuff.I have thought about using the FX-3 USB 3 chip myself and making my own but of course the development time would be high. It is also only BGA. FTDI has some USB 3 FIFO chips that look possible too but again lots of driver work and more to get it going.So bottom line: what are the options out there? Seems like this should be a solved problem with a low margin off the shelf option -> a fat low latency pipe from a computer to an FPGA.What do you use?

author: Foxxz
author_rank: Regular Contributor
timestamp: January 08, 2022, 10:16:28 pm
content: I was going to suggest the FX3 until you ruled it out. Not sure how much driver work needs to be done as I've seen these paired with plenty of FPGAs.I might suggest an FTDI FT2232H which is USB2 but the driver work would be little to nothing.There are FPGA PCIE bridges out there for which the driver is free but you license the IP to use in your design. If you need it to be detachable I have gotten it to work over lightning ports.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 08, 2022, 10:19:01 pm
content: Quote from: Foxxz on January 08, 2022, 10:16:28 pmYes, drivers are available for all major platforms, plus a decent API.They absolutely have USB 3 SS chips these days. FT6xx series. Not only are they no work for the drivers, but they are also significantly cheaper than the FX3.

author: drwho9437
author_rank: Regular Contributor
timestamp: January 08, 2022, 10:27:56 pm
content: Quote from: Foxxz on January 08, 2022, 10:16:28 pmI'm not ruling out the FX3. It seems like a lot of people have selected it so it must have something going for it but I'm not that strong on USB driver classes. FTDI has a USB 3 chip that is a hard wired FIFO of some kind in a somewhat easier to solder QFN than the FX3 BGA. Not sure if there is a serious drawback to the FTDI solution.

author: drwho9437
author_rank: Regular Contributor
timestamp: January 08, 2022, 10:30:25 pm
content: Quote from: SiliconWizard on January 08, 2022, 10:19:01 pmHave you use the FT6xx series? I looked at the docs but it wasn't clear exactly what the PC interface would look like via the standard driver. Development board is about 100 dollars and I considered getting it and the cyclone dev board it mates to just to figure out how to use everything that way. Probably sell the cyclone board after I understand everything was my first line of thinking.Wonder if there are other options with higher levels of integration though like the Opel Kelly stuff but less expensive.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 08, 2022, 10:35:42 pm
content: Quote from: drwho9437 on January 08, 2022, 10:30:25 pmNot yet, but you can read the doc here:https://ftdichip.com/wp-content/uploads/2020/08/AN_379-D3xx-Programmers-Guide-1.pdfI have used the USB 2 HS parts a lot though, with their D2XX drivers, and the API looks absolutely similar.Pretty easy to use.

author: asmi
author_rank: Super Contributor
timestamp: January 08, 2022, 11:14:33 pm
content: Quote from: drwho9437 on January 08, 2022, 10:30:25 pmI have used FT601 with Artix-7 FPGA, and was very happy with the results. They provide a library for PC side (along with drivers of course) which you can use in C/C++ or .NET, I used the latter and was able to reach about 325 MBytes/s of sustained data bandwidth (that's the real speed your application is receiving data at after all overheards are accounted for). On FPGA side it's just a simple FIFO-style interface. I used it on my own custom board, so not sure how it works on their devboards. The only real challenge is figuring out a way to route so many parallel traces to FPGA without getting crosstalk issues. If you don't need that much of a bandwidth, you might want to use FT600 instead as it uses only 16bit wide data bus (as opposed to 32bit for FT601).This is as "off the shelf" as it goes in this business, FPGA side interface is not much more complex than interfacing with internal FIFO, you can choose the frequency it runs at between 66 and 100 MHz (I used the latter, the former will reduce available bandwidth), and it's just a few lines of code on the PC side (at least using their .NET library).Ethernet is much more complicated solution than FT60x, not to mention if you do need something close to 2.5 Gbps which they provide. PCI Express is even worse as it requires using dedicated multi-gigabit transceivers, as well as writing a driver on the PC side. Xilinx provides a free IP and a driver, but it's only for Linux. other vendors charge big $$$ even for IP.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 08, 2022, 11:30:03 pm
content: For the FT232H/2232H, the synchronous FIFO mode is a "master" FIFO - the FT part provides the clock. So either you can use the same clock throughout your design (but beware this clock will stop when the communication is closed), or you need to synchronize between clock domains. Not a big deal, just something to keep in mind.I'm not sure about the FT6xx - I think they act as FIFO slave, thus you provide the clock, which makes things a little easier - but asmi can confirm.

author: langwadt
author_rank: Super Contributor
timestamp: January 08, 2022, 11:34:52 pm
content: Quote from: SiliconWizard on January 08, 2022, 10:19:01 pmyes, good for about 40MB/s in fifo mode and you can use the second interface to configure the fpga

author: asmi
author_rank: Super Contributor
timestamp: January 09, 2022, 12:02:59 am
content: Quote from: SiliconWizard on January 08, 2022, 11:30:03 pmNo, it's a master too (meaning the chip provides the clock), but you are likely want to have FIFOs on FPGA side as well to cross into whatever clock domain your design is running at, so it's not a big deal.

author: voltsandjolts
author_rank: Unknown
timestamp: January 09, 2022, 03:14:09 pm
content: cross-refto another thread and an interesting post about fx2pipe for cypress fx2 (never tried it myself).

author: NorthGuy
author_rank: Super Contributor
timestamp: January 09, 2022, 06:53:36 pm
content: It is huge difference in speed between USB 2 and USB 3. The USB 2 solutions are abundant. USB 3 options are very scarce. All I could find is Cypress FX3 and FT601. FX3 is expensive, complex, and poorly documented. So, I made a prototype board with FT601. It worked well. It took me less than a day to begin communicating with FPGA through their library.The FT601 FPGA FIFO interface is rather straightforward. The timing requirements in their documentation are very strange. They require huge hold time (4.8 ns) which is absolutely impossible to meet. They have an XDL example where they "forgot" to put minus - they have "set_output_delay -min 4.8" instead of "set_output_delay -min -4.8". This certainly passes timing analysis every time. But if you put the "minus" in, it's utterly impossible. Even though I had some help from the trace delay (400 ps), I could only meet 2.3 ns hold. This worked well at 100 MHz, buf failed at 66 MHz. From which I concluded that 4.8 ns is either bogus, or reflects only the worst case (66 MHz at 1.8V).The DLL works, but is cumbersome, loads slow (300 ms), and is somewhat buggy. FT601 doesn't really do FIFO, rather block transfers with FIFO interface to FPGA. If you do simple block transfers with blocks of the fixed size everything works. With variable block size it becomes less reliable. Sometimes the read function returns with data size less than requested (contrary to the docs). If application quits without reading all the requested data, next time the DLL loads, it can read leftover data from the previous start. Sometimes it simply hangs and starts returning errors on all reads.I couldn't get full speed from the DLL (381 MB/s), even when reading one long block. No matter what you do there are delays between blocks, so you realistically get 320-340 MB/s. While analyzing delays on the FPGA side I noticed that gaps between blocks are typically small, but sometimes there are longer delays as well. The nature of these delays is unknown. May be FT601 limitations. May be DLL problems.It should be possible to figure out the USB protocol directly and get rid of the DLL, fixing the bugs, and possibly improving performance. I was going to explore this opportunity, but by that time the cheap Xilinx FPGAs turned into unobtainium and the project was scrapped.

author: drwho9437
author_rank: Regular Contributor
timestamp: January 09, 2022, 11:07:31 pm
content: Quote from: evb149 on January 08, 2022, 10:59:49 pmI have certainly thought about going the Ethernet UDP route for a long time but I have dithered on it. PCIE is a no, I want the box on a cable. I don't think the dev kits are a problem I just want to know the market before I invest the time. Still not sure if there are any higher level of integration other than Opal Kelly. I agree though GigE would be lower cost and in some ways simpler.

author: drwho9437
author_rank: Regular Contributor
timestamp: January 09, 2022, 11:10:15 pm
content: Quote from: asmi on January 08, 2022, 11:14:33 pmVery helpful advice. I might try to build a custom Max10 + FT600 board and see how far I get.

author: drwho9437
author_rank: Regular Contributor
timestamp: January 09, 2022, 11:16:53 pm
content: Quote from: NorthGuy on January 09, 2022, 06:53:36 pmVery interesting hopefully you will unscrap it if the chip shortage eases. I think a well documented reference big pipe OSH design could benefit people a lot. In my mind something like a Max10 base able to pull some LVDS lines to some DAC/ADC would be a thing that would be pretty enabling.I didn't completely follow your timing issue but I guess I would figure it out when I get there. I haven't made a comparison between the FT6xx and the older FT FIFO stuff. Other than the PHY is there much difference in using them? I'd rather standardize my design on something future looking even if the older USB 2 FIFO is a tiny bit easier. If it is a lot easier perhaps I should rethink.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 11, 2022, 03:12:08 am
content: Quote from: drwho9437 on January 09, 2022, 11:16:53 pmUSB 2.0 full speed uses 480 MHz signaling. This will give you 50 MB/s at the very best. If this is sufficient for you, I would definitely go with USB 2. I don't know what you mean by "easier", but it's certainly much cheaper, uses slower signals, saves space on PCB, and gives you more options. If you need 50 MB/s or more, then USB 2 is not fast enough for you.

author: Someone
author_rank: Super Contributor
timestamp: January 11, 2022, 03:51:01 am
content: Quote from: drwho9437 on January 09, 2022, 11:16:53 pmPick your favorite open source SDR.spoiler... they mostly use FX2/FX3 chips!

author: laugensalm
author_rank: Regular Contributor
timestamp: January 11, 2022, 12:34:47 pm
content: One more thumb up for all the GNU radio derivatives, they offer the best FX2 code I've seen so far. Similar usable reference designs are found for FX3 *without* the flaky ThreadX framework (flaky as in introducing spurious DMA timeouts).However, I'd definitely go with UDP over GigE these days, the software overhead for USB host-side (drivers, VID/PID handling) plus embedded firmware is way over the little more expense for the ethernet streaming logic. Especially if out of band messages are to be transmitted, Ethernet does the better job. Depending on what you're streaming, you might also rather try compressing it (DPCM, context based prediction, etc.) instead of driving your interface near the maximum possible data rate.

author: voltsandjolts
author_rank: Unknown
timestamp: January 11, 2022, 01:07:19 pm
content: Quote from: laugensalm on January 11, 2022, 12:34:47 pmCan you provide a link to your recommended fx2 code please?

author: laugensalm
author_rank: Regular Contributor
timestamp: January 11, 2022, 02:59:43 pm
content: This is the most recent I've found (my repo clones are kinda outdated).https://github.com/EttusResearch/uhd/tree/master/firmware/fx2Also, you might find derived code around all 'usbjtag' related source, at least for bulk transfers. All this code should compile with the license-free SDCC, I just remember some hickups with the migration to SDCC v3.

author: Morgan127
author_rank: Contributor
timestamp: January 11, 2022, 08:33:51 pm
content: I can recommend you to have a look at theEthernet cores from FPGA-Cores.com.These are very easy to use and you get UDP / TCP and other stuff like remote programming, logic analyzer etc.No charge for private projects. Free to download. I use them in almost all my projects.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 11, 2022, 09:02:27 pm
content: Quote from: Morgan127 on January 11, 2022, 08:33:51 pmLooks like these are RMII (10/100Mbit Ethernet), which is even slower than USB 2. Various methods can be ranked by their speed as follows:USB 3 > Gigabit Ethernet > USB 2 > 100Mbit Ethernet

author: Morgan127
author_rank: Contributor
timestamp: January 12, 2022, 05:50:23 am
content: Quote from: NorthGuy on January 11, 2022, 09:02:27 pmThere are MII, RMII, GMII and RGMII so also Gigabit Ethernet.

author: drwho9437
author_rank: Regular Contributor
timestamp: January 22, 2022, 07:17:36 pm
content: For industrial application GigE or other Ethernet is good but the switch is some overhead and power over Ethernet is a thing but not as simple. I am going to take a look at the FTDI 16-bit FIFO chips in a bit more detail and see how far I get I think. My preliminary pick is 10M02SCM153 + FT600 -> connector. Sometimes I don't have time to really get into this stuff so we will see how far I get. This work isn't my highest priority but its somewhere on the list.

author: jevinskie
author_rank: Newbie
timestamp: January 24, 2022, 01:44:46 am
content: You might like this Atrix 7 35k paired with a FX3:https://m.aliexpress.com/item/1000006618157.html

author: FlipFlop10
author_rank: Newbie
timestamp: February 09, 2022, 06:03:22 pm
content: Quote from: NorthGuy on January 09, 2022, 06:53:36 pmThe timing diagrams show that you should use the falling edge of the clock to change data/control signals. However, the hold time is specified from the rising edge. With a period of 10 ns, you should be able to satisfy the hold requirement when launching data on the falling edge (5 ns delay) + clock to output delay and delay on your board. The output delay constraint is indeed nonsense

author: NorthGuy
author_rank: Super Contributor
timestamp: February 10, 2022, 04:28:43 am
content: Quote from: FlipFlop10 on February 09, 2022, 06:03:22 pmThe hold time (T4) is the time you must keep the data line stable after the rising clock edge. It is 4.8 ns. Then there's 4.2 ns window when you free to change the data. The new data must get stable 1 ns before the next clock, which is the setup time (T3).4.8 + 4.2 + 1 = 10 (the period).If you drive the data back straight from the IOB flop using the FTDI clock, this will be fast enough to meet the setup requirement, but the data may change whole lot faster than 4.8 ns. If you insert a delay to circumvent this, you will no longer be able to meet the setup requirement.