Setup: XEM3005, C++ FrontPanel API, Mac OS X
I am trying to put a data acquisition system together and have had some trouble. I isolated my problem to timing in the block-throttled pipe-out transfer. When I do a transfer of 8 MB with a block size of 1024 bytes, there is a pause in the transfer after the first two blocks (2048 bytes). The pause can be between 15 and 30 ms. After that point, the rest of the transfer seems to go along just fine. I’m doing this in C++ under Mac OS X with a call to ReadFromBlockPipeOut.
When I transfer larger amounts of data with successive calls to ReadFromBlockPipeOut, I see a timing gap between the calls (which cannot be avoided), but I also see the pause mentioned above after 2048 bytes for each call.
I could get around the 15 to 30 ms lag by buffering data to RAM. The data rate is too large to buffer on the FPGA for this length of time. But, I wonder why there should be a lag within the transfer at all. The overall throughput is good at 25 MB/s.
My data acquistion code includes a FIFO between the data collection and the block throttled pipe. I stripped out everything except what I used to watch the timing and the resulting Verilog file is attached. The code counts cycles of ti_clk at 48 MHz and feeds bits 25 through 10 to the pipe so that each increment of the words in the output on the host corresponds to 21.33 us. I saw gaps between 750 and 1500 in the final data.
When I reduced the transfer block to 512 bytes, the lag was observed after 1536 bytes being transferred. Three blocks in this case as opposed to blocks in the tests with blocks of 1024 bytes.
I hope that this lag can be eliminated. Or documented.
I also would like to see the maximum transfer size increased from 16777215. Why not 4294967295? I’m not sure that I could use 4 GB, but I could use more than 16 MB.
pipe_time_test.txt (1056 Bytes)