Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

FPGA XDMA read burst from FIFO issue

0

Hi,

backgroud: I have created an FPGA design based on the cl_dram_dma that processes DMA stream received by pcis axi bus and then my CL sends back the results in an output FIFO that is connected also to pcis axi bus (read channel), using FPGA F1 and XDMA.

This worked for worked for a while and recently I have two problems:

  1. The stream to the host is stuck and statistically after rerunning the server the XDMA works again.
  2. When 1 works, in the read burst stream the XDMA / shell misses a beat that causes the system to halt as I see that the host empties the FIFO (let's say we had 6 entries there) and it reads 5 and one is lost

Have you faces this issue?

Thanks, Essam

Topics
Compute
Tags
Amazon EC2FPGA DevelopmentCompute
Language
English

asked a year ago214 views

2 Answers
1

Hi Essam,

A couple questions that would help us better understand your issue:

  1. Is this an existing AFI that used to be working or a recently re-built one?
  2. When you mentioned "after rerunning the server the XDMA works again", what exactly did you do there? Did you reboot the host or create a new instance?
  3. When the XDMA stream is stuck, do you still have access to the shell, e.g. through the OCL or BAR1?
  4. Have you checked the metrics to see if there is any error reported on the PCIS interface?

Thanks,

Chen

AWS

answered a year ago

  • User-3279441
    a year ago

    Hi,

    1. build like a month ago and worked back then
    2. I rebuilt the XDMA and reinstalled it
    3. shell works, it timeouts more precisely, I inserted an ILA to see what happens inside the HW, and I see that I requested a data in size of 384, which is 6 beats of data. I have two scenarios: a. I run the application without prints into a file and it works properly, I get arlen=5 (which is 6 beats in AXI bus as expected) b. I run the application with prints into a file and I get a timeout. I see that my burst is separated into 2 bursts, one with arlen=4 (meaning 5 beats) and the second one is with a arlen=1 (which is 2 beats!!). Therefore, my assumption is that there's a bug in the XDMA or the FPGA F1 HW shell
    4. I have checked the metrics and there's a timeout error in PCIS as expected

    Moreover, I'm debugging the XDMA using dmesg and I see that the source of the issue (not necessarily a bad behavior) is that in the scenario b, we get a buffer which is not rounded to a PAGE and that causes a generation of two descriptors instead of 1. the lengths are ok as I see, I guess something from this point until we get the data into the AXI PCIS bus causes an extra beat to rise

0
Accepted Answer

Issue solved by writing to and from page size aligned buffers with length aligned to PCIE, I used posix_memalign linux function to allocate the buffers.

**More details: ** After some debug of the design (using on-chip-debug ILA), and XDMA debug with dmesg, I have solved the issue, as I'm trying to work in non-incremental burst mode (I don't can about the address as I'm reading from a FIFO). The system as-is right now is capable of reading continues regions. when it comes to reading from a FIFO instance, that an entry in it can be read only once (you can't read half of it and try to read again the other half) there's a problem, because the XDMA tries to read to buffer in page alignments and when the destination buffer isn't aligned to such an alignment another read might be done or a data is lost when moving in between pages (that's why I had a weird issue between two different runs with same code and same design).

Therefore, reading from the XDMA is such cases is recommended to be in page aligned buffers with data size equal to the PCIE width (64B).

Hope this is helpful for other people!

Thanks, Essam

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content