[Gb-ccb] USB test results

[Martin Shepherd]

I'm relieved to report that I have now been able to verify first-hand
that the USB 1.1 chip that I have been advocating, will easily satisfy
the data readback needs of the CCB, and won't hammer the CPU in the
process.

It has taken me longer to verify this than I expected, firstly because
coming up with a test handshaking circuit turned out to be a bit more
of a challenge than I was expecting, and secondly because when the
existing Linux device driver for this chip proved incapable of
providing the data throughput needed by the CCB, I ended up having to
write my own device driver.

Using my custom device driver for this chip, I now repeatably measure
continuous read and write speeds of 940KByte/s and 985KByte/s
respectively, with average CPU loads of just 2% and 5%, respectively.
I have verified that the returned samples when reading, really do
reflect the logic levels at the data pins, and that the data pins
reflect the values that I send them when writing to the chip. The
measured maximum throughput is almost four times the 256KByte/s that
we need for streaming integrated data back from the FPGA, and means
that we will be able to also stream back the larger dump-mode data
sets at almost 1MByte/s.

The details of my tests follow.

The hardware test rig
---------------------
Originally I had been intending to plug two FT245BM chips into
different USB ports, connect the data lines of one to the other, and
cross-wire the read and write lines of the two chips, so that what I
wrote to one chip, I could read back from the other chip. This, I
thought would allow me to get the two chips to provide each other's
handshaking signals, so that I wouldn't have to build a custom
handshaking circuit. Unfortunately, the handshaking protocol is such
that if I had tried this, the two chips would have just ended up
waiting forever for the other chip to drop its handshaking line
first. So I abandoned this idea, and instead decided to perform the
test with just one FT245BM chip, along with a custom handshaking test
circuit that would execute as fast as possible, so as not to have
handshaking limit the I/O speed.

The handshaking circuit that I ended up breadboarding, involved a pair
of monostables, generating 100ns read or write pulses, separated by at
least 100ns. This circuit started a new train of pulses whenever the
read-enable or write-enable enable line became asserted, and new
pulses continued to be generated until the enable line became
deasserted again. Since this handshaking circuit was capable of
filling or emptying the FIFO at 5 times the maximum expected 1MByte/s
throughput, this ensured that the USB link would be the limiting
factor, not my handshaking ciruit.

The software test setup
-----------------------
For the software end, I first tried using the existing linux USB
virtual serial port driver for this chip. This driver was originally
written for the serial variant of the FT245BM chip, called the
FT232BM, but the two chips apparently use the same firmware, so the
same driver also works with the FT245BM. However it isn't optimized
for the FT245BM, and is slowed down by the overhead of the Linux
terminal I/O layer. Thus, even after disabling all terminal I/O input
and output processing options, (and fiddling with every other
configuration parameter that I could find in the driver source code),
the test program that I wrote to use this driver couldn't get the
driver to read data from the chip faster than 250KByte/s, compared to
the required 256KBytes/s.  It would, on the other hand write at
800KByte/s, which showed that the USB link was capable of going much
faster than the read speed indicated. I sent an email to the
manufacturer, asking whether there was something fundamental that
caused the read and write speeds to be so different. I finally got a
message back saying that the low read speed was due to the USB
host-adapter time-sharing the expected 1MByte/s between 8
devices. Since I only had one device plugged into the USB port, and
the observed 250KByte/s isn't 1/8th of 1MByte/s, this was clearly
bogus.

After giving up on the existing driver, I started writing my own
minimal test device-driver that wouldn't be bogged down by the serial
I/O layer of the older driver. This was a lot of work, which is why it
took me a couple of days, but the results were worth it, once I
figured out how to buffer things properly.

Having measured a 985KByte/s write rate, I set about verifying that
the data that I was sending was actually appearing on the data pins of
the chip. Since I had filled the 40MByte buffer that I was sending to
the chip with a ramp, modulo the 8-bit data size, I expected the
signal on a given data pin (n=1..8) to be a square wave with a period
of DataRate/2^n.  I verified that this was the case for each pin,
using an oscilloscope.

The read transfer rate that I measured was 940KBytes/s. To check that
each of these samples actually reflected the logic levels at the
data-pins of the FT245BM, I first checked that touching a pull-down
wire to each of the pins in turn, generated the expected values. This
couldn't prove that each sample was really correctly sampling the
value at each pin, however, so I then strung a couple of 4-bit
counters together to form an 8-bit counter, and connected the clock
input of the combined counter to the "write" pin of the FT245BM, so
that it would be incremented by one, as each sample was latched in by
the FT245BM. I then connected the data outputs of the counters to the
FT245BM inputs, so that the returned data ought to show the
monotonically incrementing value of the counter.  I then wrote a test
program to print out all of the values that the device driver read
from the FT245BM, and verified that each sample was one count bigger
than the previous one, first by eyeballing the data, then using an awk
script. I checked this up to 25 million samples, without seeing any
missing counts. Thus I am now confident that my driver really is
reading the data pin values at the measured 940KByte/s rate.

Martin