[Gb-ccb] USB test results

[Brian Mason]

hi Martin- I second Randy's "well done" for clearing this hurdle.

What OS was your driver written for? (RH9?) 

 -Brian

On Fri, 19 Mar 2004, Martin Shepherd wrote:

> 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
> _______________________________________________
> gb-ccb mailing list
> gb-ccb at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/gb-ccb
> 

-- 
--------------------------------------------------------------------
Brian Mason                           | office: +1(304)456-2338
Assistant Scientist                   | fax:    +1(304)456-2229
National Radio Astronomy Observatory  | mail:   PO Box 2 
bmason at gb.nrao.edu                    |         Green Bank, WV 24944
http://www.gb.nrao.edu/~bmason/       |
--------------------------------------------------------------------