Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length.

[lordcape]

Hi. I have a proposal for a project where I have to manage the samples of an ADC of 8 bits @ 100 MHz. I have to deliver the samples to a PC quite fast, so I think that the FT600/601 would be a nice choice for that. The thing is that I've used in the past the FT232H with the FIFO sync mode (60 MHz clk FIFO) and the bottleneck where in FTDI D2xx drivers...they limited my data transfer speed much below the 480 Mbits of USB 2.0 (and in Windows worked faster than Linux, FTDI support said in that moment).

So I write this post to ask you if you (people of FTDI) have a practical (not the theoretical 5Gbps) number of the transfer rate in MB/s with the FT600/601 working in SYNC FIFO using D3xx drivers. My application needs 100 Ms/s maximum but if I use the 32 bits parallel FIFO I only would need 25 Ms/s. I would like to have a good margin to be sure that I don't loose samples (as in my FT232H old project)....

Thanks and regards

SR

[FTDI Community]

Hi,

Thanks for your question. If you email support directly on support1@ftdichip.com they can take a look more closely at your question and get back to you.

Thanks,
FTDI Community

[asmi]

I have FT601 on my own custom board with Artix-7 FPGA. When FT601 is configured in 1IN/1OUT (single bidirectional pipe) mode, I was able to get ~330 MBytes/s of "real" read bandwidth (meaning this was a rate I was getting an actual data out of D3XX API, so all overheads are factored in), same chip on a same board with FT in 2IN/2OUT mode - I was getting ~220 MBytes/s of read bandwidth out of a single IN pipe. The board used FT601 with 32bit bus running at 100 MHz and with Vccio of 3.3V.

Please note that you can configure FT to only have a single IN (or OUT) unidirectional pipe if you don't need two-way communications (or if 2 GPIOs are enough for your OOB needs), this will likely push the bandwidth towards 400 MBytes/s or so.

So that's going to be more than enough for your application. Infact you can probably get away with 16bit model, but don't quote me on this.

[lordcape]

Thanks asmi for your answer. Very helpful to me. Regards

SR

[Bob]

Hey guys.
I would like to reopen this issue. It seems that I stuck with the same problem as lordcape. We've got an application using Ft601 where we need to stream data to a PC. We only get data rates of about 50MByte/s.

We are using FIFO Clock of 100MHz, 245 Mode and 1Channel.

I do believe that the bottleneck is inside the PC - I think the PC is not getting the data fast enough out of the driver.

Any suggestions why we only get 50MByte/s? Lordcape, did you solve your issue?

Best regards
Bob

[lordcape]

Hi Bob. Yes, we have solved our issue. I don't remember quite well which was the puntual solution. I have some recomendations here that perhaps can help you:

1. You should program one long USB session (one call of the FT_Read
API) or queue appropriate number of the asynchronous FT_Read. You must
have queued transfers in D3xx/driver at any time. The ulBufferLength
parameter in FT_ReadPipe can be set to be able to deliver block of data
at constant rate. Try
ulBufferLength = 262144 or 65536 or >262144.

2. You must add memory buffer, e.g. FIFO, RAM, in FPGA side. It
prevents data loss when writes to FT60x are temporary impossible due to
USB protocol or USB transfers management in software.  The connection I
tested was with 80 kB additional FIFO buffer and queued transfers (Fig.
6). For 100 MB/s the buffer size may be smaller. Try 32-64 kB.

3. FPGA master should write data in burst transactions with the size of
4096 B (245 mode, 1 EP IN, 1 EP Out). It is pointed in  FTDI
application notes. The transfer is finished when short packet is
written to FT60x. If you write e.g. 4 samples 32-bit, stop, write
again, it is impossible to achieve 100 MB/s throughput.

4. For the best throughput, consider the FT_StreamPipe API. Transfer
switching is more lightweight when this function is used. But
additional memory buffer was still required.

5. Some steps to synchronize OS environment and the application may be
required. Consider continuous work with dummy data at the beginning and
valid data streaming after command trigger.

Two years ago I found a paper called "An Universal USB 3.0 FIFO Interface For Data Acquisition" by Krzysztof Mroczek and I wrote to him and he gave me those recomendations.

Best regards,

SR