Ft2232h fifo realtime data stream

[sink]

Hi everybody
I'm thinking about software defined radio which incorporates some fpga, adc,dac, and ft2232h as usb converter. I wanted to ask, how should i implement a deciding in FPGA when I'm transmitting a valid data to DAC, and whether I send  some signaling commands to fpga. I'm asking because I'm afraid I will lose a some important bytes of RF data when pc will send a header to fpga(which informs about purpose of fed data). How should i implement this distinguishion?

Thanks in advance
SiNk

[TomS_]

Real time applications (think along the lines of streaming video) rely on the ability to supply new data faster than it is consumed, which means buffering a certain amount before beginning consumption, and being able to resupply the buffer quickly enough once you reach a "low water mark" to prevent exhaustion.

So depending on how quickly the FPGA is going to consume the data you send it, you'll have to determine what kind of bit rate you need to be able to supply data to prevent your buffer being exhausted, taking into account the headers that you need to send it as well.

I would not rely on real time streaming of the data to the FPGA over USB, as there is no guarantee about what kind of jitter you will encounter, so this will likely not result in a smooth supply of data. If you must go down this route, at the very least you should have a small buffer, but you'll need to do some experiments to determine how big that should be, or allow it to be configured.

[BrianHG]

Experiments with FTDI's regular FT232 USB <-> RS232 converter has proven that without any handshaking, with a proper UART in the FPGA, ~50% of 921600 baud can be sustained error free full duplex with 2 kilobyte chunks being transmitted and received back and forth.  So, if you can operate with <46 kilobytes a second, then the following example has been shown to work:

See my example UART & debugger utility here : https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/msg2801388/#msg2801388

FTDI's parallel interface USB chips should be able to burst faster.  Higher baud rates require hardware handshaking for reliable results.  Read up on FTDI driver 'Latency timer' as it will be crucial to set in your streaming app.  You can set it when directly opening their driver, or, read further in my thread in post #4 which will show you how to lower their com port default latency.  (Only recommended for dev and testing, it is better for you to specify the timeout latency in your PC controller app as Windows may forget this setting upon device removal.)
 

[SiliconWizard]

There were other threads about this.

With FT2232H/FT232H devices, you can get a sustained 6-8 MBytes/s in FT245 mode (asynchronous parallel), and around 30 MBytes/s in parallel synchronous mode. I've done it, so those are real figures.

Whereas the FT245 async mode is easy to deal with, and the above throughput relatively straightforward to achieve, the synchronous mode is not as trivial to use, and getting a sustained 30 MBytes/s requires a lot of care, especially on the software (host) side.

Then if the above is not enough, you can take a look at the USB 3.0 SS devices (FT60x, Cypress FX3...)

[DiTBho]

is there any working opensource example about that? both HDL and host code?

[DiTBho]

Ot:
not strictly related, but I need to move constantly about 4Mbyte/sec of data (it's a kind of logger with special processing), and I am thinking about using an Ethernet 100Mbit/s chip. There are some that provide the MAC and PHY layers, and a little FIFO managed in parallel synchronous mode.

I haven't decided anything yet, but in this case I will for sure use a simple udp/ip protocol, implemented inside the FPGA in a simple softcore.

What tempts me is that I prefer this solution for the host-side.

[sink]

Thanks for the answers

So depending on how quickly the FPGA is going to consume the data you send it, you'll have to determine what kind of bit rate you need to be able to supply data to prevent your buffer being exhausted, taking into account the headers that you need to send it as well.

I think about something around 20MSPS(my dac will run with reduced clock of 20MHz) ,each RF sample will have 10 bits, so only baseband byterate is 25MB/s.

If you must go down this route, at the very least you should have a small buffer, but you'll need to do some experiments to determine how big that should be, or allow it to be configured.

Thanks for that advise. I really want to go USB to have compatibility with modern laptops.

There is something another which bothers me. When signal will flow from PC to fpga, in the moments when the header bytes(one or two maybe) will flow, there will be no data going to the buffer. Does it introduce a problem?

There were other threads about this.

With FT2232H/FT232H devices, you can get a sustained 6-8 MBytes/s in FT245 mode (asynchronous parallel), and around 30 MBytes/s in parallel synchronous mode. I've done it, so those are real figures.

Is it possible to use ft2232h as a bitstream loader, in MPSSE mode(on channel B), and then after booting it, switch usb controller to Synchronous 245 FIFO mode(on channel A)?

Whereas the FT245 async mode is easy to deal with, and the above throughput relatively straightforward to achieve, the synchronous mode is not as trivial to use, and getting a sustained 30 MBytes/s requires a lot of care, especially on the software (host) side.

I will try my best

[langwadt]

Is it possible to use ft2232h as a bitstream loader, in MPSSE mode(on channel B), and then after booting it, switch usb controller to Synchronous 245 FIFO mode(on channel A)?

yes I've done it, The ftdi needs an eeprom to enable the Synchronous 245 FIFO mode, but you can still switch between
modes in software

[sink]

Thank You! That was the thing which bothered me the most. It's nice that I can eliminate external STM32 with flash containing multiple bitstream images which was intended to load selected one.

[laugensalm]

You might want to look at the GNUradio (old FX2 based USRP hardware) project.
The FT2232(H) does not support isochronous mode, for bulk you'll need to buffer which may involve RAM. For continuous streaming, I'd strongly recommend going isochronous or use a RTP/UDP based solution using chained DMA descriptors (see https://section5.ch/index.php/2017/05/10/dma-autobuffering-techniques/) . The FT2232H also introduces FPGA interfacing timing issues that the FX2 does not have, on the other hand, there's a bit of overhead configuring the firmware for the FX2.
You'll find a lot about this on the web.