Hello!
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:
- 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. - 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.
Regards
Pawel Kopyt