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
|
