Hello Forum!
I am using the TE0300 with a modified reference design. Instead of the XPS_FX2 I have connected my own component to the XPS_NPI_DMA module. My component is intended to read samples from a ADC and to perform some DSP on them.
I have connected a 32-bit wide (standard type) FIFO generated with the Xilinx core generator to the DMA_IN port and have connected the Valid signals together as well as the ready signal of the DMA_IN port to the rd_en port of my fifo.
To test this setup I have created a counter which fills up my FIFO. The software initiates a 1408 Byte DMA transfer and sends this data via an Ethernet connection.
Now here is my problem:
When not resetting the XPS_NPI_DMA component after each DMA transfer I am getting random data jumps I cannot explain. However, I am still seeing a jump in the data which occurs everytime I reset the dma controller, i.e. after each transfer. It seems like approx. 50 words are getting lost during the reset.
Another thing I discovered is that the XPS_NPI_DMA_WriteRAM_Blocking() function always returns 0. Even after reset the XPS_NPI_WrDone() function returns 0 and I expected it to return 1, as it is written in the documentation. I assume this might be a bug in the XPS_NPI_DMA_WriteRAM_Blocking() function.
Thanks in advance!
Cheers,
Martijn
Hi Martijn,
The XPS_NPI_DMA is unfortunatelly far from being perfect. There are some limitations which were found recently:
1. DMA_OUT port throttling with RDY signal is working properly ONLY in single beat transfer (packet size = 0)
2. DMA_IN port works properly ONLY if you push in word by word with a pause of minimal 1 cycle.
I think you have encountered the limitation #2. Just make sure that obey the rule. I had not enough time to fix all this things so far. Any help would be more than welcome. The problem with limitation #2 could be a serious problem at very high data rate.
About the XPS_NPI_DMA_WriteRAM_Blocking() and XPS_NPI_WrDone(): it seems that you do not fill the data into the FIFO or the DMA is locked in any way. XPS_NPI_DMA_Reset(NPI_DMA_TYPE * DMA) is not a real reset since it only resets FIFOs and clears the registers.
What did you input for XPS_NPI_DMA_SetWrBurstSize(Xuint32 BaseAddress, Xuint8 Size)?
Best regards,
Ales
Hi Ales,
thanks for your quick reply!
Currently I am indeed writing without a pause at system clock speed (125MHz) to the fifo, I will throttle this today and recheck the measurements.
I have previously tried every possible setting of the write block size, with no change at all. The jumps were identical, regardless of the setting.
Concerning the DMA_Reset() behaviour:
I think this is a systematic problem. If you look at the NPI_WRITE_ENGINE process in dma_write_path.vhd and suppose the rst_global signal is high, the wr_xfer_done_i signal will be set to 1. After a XPS_NPI_DMA_Reset() call from the software, the xfer_write signal will also be 0. So we can assume the xfer_write is 0 and npi_wr_state is IDLE. As soon as the reset signal goes to 0, the if condition asking for xfer_write = '1' will return false, jumping into the else part. There we can see that wr_xfer_done_i is set to 0.
This means, if I am correct, that after a reset the XPS_NPI_DMA_Reset() the XPS_NPI_WrDone() will always return 0. There is no influence on the non blocking XPS_NPI_DMA_WriteRAM, because it does not check whether the write operation was done. The blocking variant checks and will always return 0, because it looks as if a write operation is currently in progress.
I hope you can follow my train of thoughts and please correct me, if I'm wrong ;)
Regards,
Martijn
Dear Martijn,
Your thoughts are absolutely right. There could be a problem with blocking function and wr_xfer_done_i signal. I usually rely on reading the current write address and the write runs as a circular buffer (loop mode).
I will keep that in mind when preparing a core revision.
If you have already solved the problem and tested functionality, then is it possible that you send us the VHDL file?
Best regards,
Ales