Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
Hello I've been using a modified slave fifo configuration based on the AN65974 application note. A Xilinx development board is connected to the FX3 SuperSpeed Explorer Kit which is then connected to a PC. We've successfully used this set up to transfer a frame's worth of imaging data for a custom ultrasound system (128KB of data per frame). Recently we've upgraded the imaging system to double the pixel density. Now for each frame we need to send 256kB of data to the PC. This is where we've been having more interesting results. When requesting 256KB using xferdata() the first 128KB correspond to the second half of the previous frame, and the second half of the data corresponds to the first half of the current frame. I've run integrated logic analyzers (ILAs) on the FPGA to ensure that the data being written to the FX3 is in fact correct, so I am certain that the problem does not lie in the writing or reading of data from the FPGA. I should also state that once the frame data is sent to the FX3 chip, the memory is cleared and thus cannot be repeated on the next acquisition. A small fix that I've attempted to implement (with moderate success) was to request a frame and a half of data (384KB). I would throw away the first 128KB and subsequently plot the remaining 256KB. This method unfortunately is not ideal for obvious reasons, but I also seem to be losing a small amount of data using this method and it manifests into a imaging artifact propagating through each image. I've also tried performing 16 sequential xferdata() calls for 16KB of data which did not sort out the problem. I've also replicated this error on our previous platform requiring on 128KB worth of data by forcing the PC to request double the amount of data from the FPGA. Since the circular buffer inside the DMA has 8x16KB = 128KB, I'm suspicious that the root cause has to do with the manner of which we're requesting data from the FX3. We've kept it relatively simple using the xferdata() function.
I'm hoping someone can give me some insight as to why the FX3 chip seems to be storing the last 128KB of data that I've transferred on the previous xferdata() request. Some insight would be greatly appreciated. Thanks in advance.
I doubt the Fx3 is reordering the two halves of the frame.
Since it is just acting as a pipe between the FPGA and the PC, it only sends the buffers to the PC in the same order that it gets from the FPGA.
My guess is that you could have only requested for 128kB of data at some point in your host app code instead of 256kB. This can lead to every subsequent 256kB to seem like it has the halves reversed, when in fact the first 128kB is the second half of the previous frame and the second 128kB is the first half of the current frame. Pls check if this could be a possibility.
Since you do not observe any errors with the data itself, I do not think it could be something going wrong in the Fx3.