PipeTest example - virtual FIFO

I am new to XEM6310 board. To start working with it, I looked into the PipeTest example. The way it works is slightly different from what I expected, though. I will appreciate very much if anyone can correct me. Here is the way I built my test based on the original source codes:

  1. The pipe_out_check.vhd contains a mechanism to slow down transfer. It seems that the mechanism works like this:
    1a) As long as the virtual FIFO holds less than 1024 words the ‘pipe_out_ready’ signal is LO, which means that the HOST should not assert ‘pipe_out_read’ signal and expect to get the data.
    1b) As long as the ‘pipe_out_read’ signal is HI, the pattern_generator output is connected to the pipe.
    1c) This means that for the first 1024 cycles the ‘pipe_out_read’ signal will not be asserted. The data generated then should be lost, since there is no real FIFO to keep them, and they are not transfered through the pipe.
  2. Since the ‘pipe_out_ready’ signal is only used by okBTPipes, keeping m_u32BlockSize at 0, will switch to okPipeOut and we always get out data regardless of the level of the virtual FIFO buffer

Taking into account the above I run two tests:

Test 1: using m_u32BlockSize = 0 I read a large chunk of data from FPGA to HOST and saved it to a file. For simplicity I used ‘sequential’ mode to have consecutive numbers in the file. At the same time I also generated the same data on the HOST side (using the generateData() function) for reference. All data (starting from 1,2, …) were transfered at full bandwidth (cir 320 MB/s) to my file confirming that the virtual FIFO is neglected when no okBTPipes are used.

Test 2: using m_u32BlockSize > 0 (e.g. 1024) I again read a large chunk of data to HOST and saved it to a file. This time I expected then the first 1024 number will be lost, and the file contents starts from 1025 or so. To my surprise, the file again starts from 1, 2, … as if no data were lost.

Based on the observations I wonder if my VHDL knowledge became so rusty I can barely understand a relatively simple code, or there is really something wrong with okBTPipeOut, which does not care for pipe_out_ready signal at all, and behaves like a standard okPipeOut?

I will appreciate very much for any hints.


Pawel Kopyt