XEM6001 - okBTPipeOut buffering

Hi there,

What is a typical buffer size you would recommend the okBTPipeOut endpoint to have?

I have an application which modifies the PipeTest example. It strips out all endpoints except the pipe_out_check, and inserts a FIFO between the data generator and the okHost. The FIFO was initially set to 4096 words, 16-bit wide, with ‘ep_ready’ hooked to a programmable fullness of 512 words (i.e., a burst length of 1024 bytes). I’ve increased the FIFO to 8192x16-bit, and still see the problem below.

The first “transfer block” of data is received without problems, we’ve tested transfer sizes of 8, 16, 32, 64, 128, 256, 512 and 1024 KBytes. However, the FIFO always seems to overflow at some point in following blocks and we see a corruption in the data. Has this been seen before?

All logic is clocked with ti_clk out of okHost.

I noticed that the example provided in PipeTest doesn’t actually have a real FIFO in it. The lfsr data is only updated when pipe_out_read is asserted, which protects against overflow conditions anyway.


  • Steph

Worth adding: input to the FIFO occurs at a rate of 13.8 MBytes/s

At that rate, you’ll fill up the 8192 in around 1ms. USB 2.0 can’t really be expected to service that sort of rate reliably with flow control. For high data rates, we recommend using much larger buffers to tolerate longer delays due to Operating System requirements. Something on the order of 10 - 50 ms would be much more reliable.

Thanks for confirming my suspicions. We have already ordered the XEM6010, which should have sufficient buffering through DDR2.

Hello again,

I now have an XEM6010 with an external 128MB DDR2. I use this, instead of internal BRAM for buffering my stream which generates data at an average rate of 13.8MBytes/s. Your recommendation was that buffering ~50ms should be sufficient. I dedicate the entire DDR2 range for buffering, which gives me ~9 seconds worth of storage. Unfortunately, the USB comms appear to ‘pause’ for a period larger than 9 seconds at some point, overflowing the DDR2 buffer.

I have nothing else running on the machine and have killed as many processes as possible. Is there some timeout setting within the driver that might be causing this long pause?


… looks like increasing the transfer length to 8MB has resolved the issue.

9s is a very long time. What transfer length were you using previously.

If you run “pipetest.exe” with the ‘bench’ argument, you can run a benchmark measuring speeds at various transfer lengths and block lengths.