XPS_NPI_DMA questions

[mfa]

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

[Ales Gorkic]

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

[mfa]

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

[Ales Gorkic]

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