FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Author Topic: FT601Q Linux FT_ReadPipe unexpected behavior  (Read 1096 times)

Petar

  • Newbie
  • *
  • Posts: 2
    • View Profile
FT601Q Linux FT_ReadPipe unexpected behavior
« on: February 12, 2021, 09:15:23 PM »

Hi all,

I made custom hardware using FT601Q and Spartan6 FPGA. I started development on Linux Mint 19.3 Cinnamon.
After making simple HDL code for FIFO 245 mode I started with streamer.cpp as a starting point.
At the beginning all was good... I changed the streamer.cpp code, so I could run just one FT_WritePipe and one FT_ReadPipe....
I was looking what is going on between the FPGA and FT601Q by using Xilinx chip-scope....
In the FPGA there is a 4kB buffer that I wanted first to write to it and later to read (loopback) and check if the read data are the same as write data....

Than I notice that when I write 4kB to FPGA and after that read from FPGA 4kB, that I am getting the same data but shifted by 4 bytes....
Than I realized (using chip-scope) that during reading at the last 32b word I made a mistake and I drive the BE (byte enable) with all zeros "0000" instead of all ones "1111".

So I was happy, I have just to fix my bug in the HDL and all will be good...

But I haven't realized that my problems only begins.

After fixing the HDL code to FPGA drive all ones at the byte enable during active data phase, FT_ReadPipe didn't work at all.
When I call FT_WritePipe and after that FT_ReadPipe, at the chip-scope I only saw FT_WritePipe consequences and no FT_ReadPipe consequences at signals between the FPGA and FT601Q...
After that I notice that when I only open the FT_Create without any other command that I see bunch of FT_ReadPipe consequences... (like something in the driver realize FT_ReadPipe from previous code run).
I also notice that what ever number I put as a BUFFER_LEN at the FT_ReadPipe, it always reads 4096 bytes, so it is no matter if I put 1024 or 4096 it always reads 4096 bytes.

After lot of time I switch to Windows 10 in order to see if the behavior is the same.

At windows I was using "FT600DataLoopbackDemoApp_v1.3.0.2" and also monitoring signals between the FPGA and the FT601Q.

At windows all works fine, so when I put BUFFER_LEN to 1024 I can see that FT_ReadPipe reads 1024 bytes.

At windows data that is written in the FPGA are the same as data read from FPGA and at the chip-scope I can see both FT_WritePipe and FT_ReadPipe consequences.

Can somebody help me.

Thanks

PS. I am making something that should work both on Windows and Linux.  Sorry for my English.
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 644
    • View Profile
Re: FT601Q Linux FT_ReadPipe unexpected behavior
« Reply #1 on: February 16, 2021, 04:39:04 PM »

Hello,

It seems that you are having issues with the Linux D3xx driver and Windows D3xx driver is OK?

Please check that you are using the latest driver versions:

https://ftdichip.com/drivers/d3xx-drivers/

Please see the following information on Transfer efficiency in D3XX Linux Library:

The D3xx for Linux library allocates a reading queue with 256 of 32Kbytes buffers internally by default at startup, it will keep requesting to the host driver until there is no free buffer in the queue, and  the library will not combine returned buffer in the queue.

  • When fStopReadingOnURBUnderrun flag is set, the FT_ReadPipe / FT_ReadPipeEx API will return immediately when encountering any buffer with length less then 32Kbytes, even if there are more filled buffers in the queue.
  • When fStopReadingOnURBUnderrun is not set, the FT_ReadPipe / FT_ReadPipeEx API will try to satisfy the requested reading size by merging all available filled buffers in the queue, buffer size is ignored.

Transfer efficiency is not determined by the reading size in D3XX for Linux, our tests showing that best performance can be achieved as long as the reading size is >= 3bytes each time.

Non 1K aligned data will cause additional process time on FIFO bus, FT600 bridge chip and USB3 bus, the overhead could cause FPGA master's FIFO buffer overflow, and wrong data will be collected.

Best performance can be achieved when FPGA is sending 1K aligned data as much as possible. If its not feasible to change FPGA's behaviour, try setting: CONFIGURATION_OPTIONAL_FEATURE_DISABLEUNDERRUN_INCHALL flag in chip configuration to remove the latency on USB3 bus.

Also try to avoid doing any heavy processing or calls to printf() from the thread which calls FT_ReadPipe(), otherwise the library's reading queue may be used up. You can use another thread to parse, or simply dump all the content into another file to verify the issue.

Best Regards,
FTDI Community
Logged

Petar

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: FT601Q Linux FT_ReadPipe unexpected behavior
« Reply #2 on: February 16, 2021, 10:04:26 PM »

Hi,

>>It seems that you are having issues with the Linux D3xx driver and Windows D3xx driver is OK?

Right.

>>Please check that you are using the latest driver versions:

>>https://ftdichip.com/drivers/d3xx-drivers/

Yes I am using the latest (0.5.21).

>>Please see the following information on Transfer efficiency in D3XX Linux Library:

>>The D3xx for Linux library allocates a reading queue with 256 of 32Kbytes buffers internally by default at startup, it will keep requesting to the host driver until there is no free buffer in the queue, and  the library will not combine returned buffer in the >>queue.

OK

>>When fStopReadingOnURBUnderrun flag is set, the FT_ReadPipe / FT_ReadPipeEx API will return immediately when encountering any buffer with length less then 32Kbytes, even if there are more filled buffers in the queue.

I am not sure what does it mean.  Does it mean that when I run the FT_ReadPipe with BUFFER_LEN parameter less than 32Kbytes, that FT_ReadPipe will return immediately without any TXE_N = '0' at the FPGA side?
Like this:   BUFFER_LEN = 4096;   FT_ReadPipe(handle, 0x82, buf.get(), BUFFER_LEN, &count, NULL))

>>When fStopReadingOnURBUnderrun is not set, the FT_ReadPipe / FT_ReadPipeEx API will try to satisfy the requested reading size by merging all available filled buffers in the queue, buffer size is ignored.

>>Transfer efficiency is not determined by the reading size in D3XX for Linux, our tests showing that best performance can be achieved as long as the reading size is >= 3bytes each time.

Right now I am not concerned about efficiency. I will be satisfied even if I reach the 100MB/s reading rate.   

>>Non 1K aligned data will cause additional process time on FIFO bus, FT600 bridge chip and USB3 bus, the overhead could cause FPGA master's FIFO buffer overflow, and wrong data will be collected.

I am not using non 1K aligned data.

>>Best performance can be achieved when FPGA is sending 1K aligned data as much as possible. If its not feasible to change FPGA's behaviour, try setting: CONFIGURATION_OPTIONAL_FEATURE_DISABLEUNDERRUN_INCHALL flag in chip configuration to >>remove the latency on USB3 bus.

I changed it but it appear that behavioral is the same.

>>Also try to avoid doing any heavy processing or calls to printf() from the thread which calls FT_ReadPipe(), otherwise the library's reading queue may be used up. You can use another thread to parse, or simply dump all the content into another file to verify >>the issue.

In the final application I will use lot of threads, and I will have single write thread and single read thread where I will only use FT_WritePipe() and FT_ReadPipe() and buffers. All threads will be protected by mutex, so I will have single operation at the time.
But this is not my concern at the moment.

For now, I just want to force FT_ReadPipe() to behave as FT_WritePipe().  So, when I call a single FT_WritePipe() (not from within the tread but from "main") with BUFFER_LEN = 64 I see that at the FPGA side there is a transfer of 16 of 32b words (so exactly 64Bytes).
When I call single FT_ReadPipe()  (not from within the tread but from "main")  I see sometimes lot of transfers from FPGA to FT601Q (each 4kBytes long) or no transfer at all (I have never saw transfer of 1024Bytes, no mater if I put BUFFER_LEN = 1024).


>>Best Regards,
>>FTDI Community

Thanks for the answer.
Petar
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 644
    • View Profile
Re: FT601Q Linux FT_ReadPipe unexpected behavior
« Reply #3 on: February 19, 2021, 04:17:15 PM »

Hello,

At USB level, the transfers are at 1024 bytes (USB3.0 – SuperSpeed) and after 4 such messages the FIFO will be full, and the USB host controller will be holding rest of the data until the FIFO is free again.
Please refer to USB Bulk transfer protocol to understand how this works in more detail.

Please try 1K aligned data in your transfer model.

If you take a look at the demo application provided with the D3xx Linux driver, it should help you.
It's contained within the driver download.

Best Regards,
FTDI Community
Logged

mgh2016

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: FT601Q Linux FT_ReadPipe unexpected behavior
« Reply #4 on: August 19, 2021, 03:51:16 PM »

Hi,
I am facing same issue in Linux. Works in MS windows. What was the solution for this issue?
Logged