libftdi Archives

Subject: toggling between reading and writing very slow.

From: Patrick Van Esch <vanesch@xxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Thu, 31 Oct 2013 16:57:42 +0100
Hello,

I'm using libftdi under Ubuntu (13.4 on a 32-bit system, and 12.4 on a 64-bit system), and I'm testing the 245 mode of the FT2232H chip using a testboard called Morph-ic II where the FT2232H is connected to a small Cyclone II FPGA from Altera. The B-channel is connected to the configuration pins (so that using bit bang serial mode one can configure the FPGA), and the A-channel is connected for 245 synchronous mode to GPIO pins of the FPGA.

The code is written in C++ using Code::Blocks and the standard g++ compiler under Ubuntu.

I started out with the D2XX driver from FTDI Chip, but I then switched to libftdi. I did 3 kinds of tests:
- reading from the FPGA to the computer.
- writing from the computer to the FPGA, and reading back to the computer
- writing from the computer to the FPGA.

In all these tests, I used quartus to produce rbf files, which were then dumped to the B channel to configure the FPGA, before switching to the synchronous fifo mode on the A channel.

My reading test was the following:
the FPGA contains an 8 bit counter which is written into a 2-clock fifo at high rate (at 75 MHz) and halted when the fifo is full, and the other side of the fifo is clocked out at 60 MHz and does the writing into the FTDI fifo if the FTDI can read, and if the fifo is not empty. On the computer side, data was read using libftdi, and checked for integrity (that is, each byte is the previous one, plus 1).

I can reach more than 20 MB per second reading of such data this way and can sustain this rate for hours, without any error. So that's fine.

My pure writing test was the following:
The computer prepares big arrays using an iterator formula: x(n+1) = (x(n) + 7) mod 233 and writing to the FTDI chip using libftdi, on the FPGA side, I clock this into a 2-clocked fifo whenever the FTDI chip wants to write, and I check at high rate (75 MHz) on the other side of the fifo, whether the iterator formula is respected. If not, I activate the led on the MORPH board. The LED never activates (I checked that it does activate when I put in other numbers in my program). So this too, can run for a long time, and I also reach more than 20 MB per second doing that.

However, when I tried to do the following:
The computer sends a small block (8 K bytes) of random bytes to the FTDI chip, where this is clocked in by the FPGA, and then the FPGA sends this BACK (using a second 2-clock fifo) to the computer, and the computer checks for integrity (that it are the SAME random numbers that were sent out), the data rate goes down to less than 4 MB per second (4 MB reading, 4 MB writing). I checked that the fifos on the FPGA are NOT full. The data integrity is OK.

In fact, looking with an oscilloscope to the TX# and RN# signals, I see that the reading and writing goes actually very fast of one block (8 K bytes), and then there is a PAUSE OF SEVERAL milliseconds, before the next salve comes, initiated by RN# signals. The FPGA gives priority to reading (so to RN#).

So it seems that it is the COMPUTER that pauses after a cycle of sending 8 KB and reading it back, which gives me a lower average data rate.

It is not my program that puts too much burden on the CPU, because I could connect simultaneously two of these MORPH IC boards with two USB cables to my computer, and run simultaneously the writing program to one, and the reading program to the other, and I kept my more than 20 MB/s rates on both programs without any problem.

When I try to increase the chunk size beyond 8 K, or I try to issue several ftdi_data_write commands before reading accumulating more than 8K, then the chain hangs (the TX# doesn't want to go low anymore, and my FPGA saturates and blocks).

I was thinking that the switching between reading and writing on USB using libftdi occured only on 1 ms frames instead of 125 us microframes, but that is not true, as during one salve, there are a few read/write inversions at close intervals on the FTDI chip (and I suppose, on the USB connection itself). But then, after the 8 K are "used up and sent back", no new RD# signal arrives anymore for several ms, and my FPGA "dries up" with all fifos empty.

As the application I had in mind was a "real time" flow in both directions with only small buffering capacity on the FPGA side (a few KB), I'm stuck: I can't bridge several ms with buffering easily.

Looking at the RD# or TX# signals in the one-way tests, there are not really such gaps of several ms.

Any idea how to avoid that ?

BTW, I'm using version 0.19 and 0.20 (because of the UBUNTU repositories and the versions I have of Ubuntu).

I switched to libftdi, because the D2XX library under Ubuntu gave poor performance in the one way reading test on my less performing machine (the 32 bit machine), where I couldn't reach more than 5-6 MB/s. Switching to libftdi allowed me (on the same machine) to go beyond 20 MB/s.

Thanks,
Patrick.

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
Current Thread