cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
11,301 Views
Registered: ‎08-27-2015

AXI DMA issues : Unable to read from a stream

Jump to solution

Hello,

 

I'm stuck configuring an AXI DMA IP. I just try to read data from a custom AXI Stream Master IP that just send the same value all the time and to write it into DRAM memory. But, for a reason I don't undersand, I am unable to do so.

 

When I observe the AXI signals with the ILA inchip logic analyser, I can observe that the TREADY signal provided by the AXI DMA IP is stuck at 0 and never goes to 1, even after starting a transfert, and I don't undersand why.

 

I joined the c code I use.

 

The AXI DMA is used with scatter-gather mode disabled.

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Visitor
Visitor
16,445 Views
Registered: ‎08-27-2015

I didn't find a solution but I realized it was simpler to directly write into RAM memory using AXI HP inferfaces than using this AXI DMA IP... So we can consider this problem is solved, I have a working system.

View solution in original post

0 Kudos
11 Replies
Highlighted
11,299 Views
Registered: ‎03-27-2014

Hi,

When I observe the AXI signals with the ILA inchip logic analyser, I can observe that the TREADY signal provided by the AXI DMA IP is stuck at 0 and never goes to 1, even after starting a transfert, and I don't undersand why.

 

I can see you are using Xilinx's API so I would assume the init_transfer() function does the right job, but to me that sounds very much like the core is not properly configured to perform a transfer.

Your init_dma() function looks fine to me.

In Vivado->Customize IP: AXI-DMA, make sure the transfer length is greater or equal to #define DMA_XFER_LEN 512,

make sure SG is disabled. With a test bench/ILA, make sure your custom IP (AXI streaming) has the right logic for the TLAST bit.

 

gw.
Embedded Systems, DSP, cyber
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
11,285 Views
Registered: ‎08-02-2011
To add to G.W., is tvalid high?

You might find these example designs helpful:
http://www.xilinx.com/support/answers/57550.html
www.xilinx.com
0 Kudos
Highlighted
Visitor
Visitor
11,240 Views
Registered: ‎08-27-2015

Hi,

 

Thank you for your help.

 

 

 

0 Kudos
Highlighted
Visitor
Visitor
11,236 Views
Registered: ‎08-27-2015

Ok, I re-checked my signals with the ALI. It seems that, even though the memory is writen, the "TREADY" signal never goes up, and because of that, the "TLAST" signal never goes up neither. I just can't undersand why I get this error flagn that seems to cause the other problems...

0 Kudos
Highlighted
11,225 Views
Registered: ‎03-27-2014

I also have a feeling the custom AXIS IP is the problem because it seems like AXI-DMA is configured properly.

The best thing you could do is write a test bench and maybe share a screenshot of a complete frame.

 

TVALID cannot be always '1' on your AXIS-master side, it should be '1' as soon as TREADY is '1' (DMA-ready), and TLAST should be high for a single TVALID

gw.
Embedded Systems, DSP, cyber
0 Kudos
Highlighted
Visitor
Visitor
11,195 Views
Registered: ‎08-27-2015

Hi,

 

I think I misundertood the goal of TVALID. I thought TVALID had to be 1 before the slave can set TREADY to one, and not the opposite. Do you confirm ?

 

I joined a printscreen of the chronogramme I obtain in simulation after modification. Do you think it is normal ?

 

Thank you for your help !

Screenshot from 2016-03-03 09^%23^%35.png
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
11,176 Views
Registered: ‎08-02-2011
I thought TVALID had to be 1 before the slave can set TREADY to one, and not the opposite. Do you
confirm ?

That's right, tvalid should not depend on tready. You should assert tvalid as soon as you have data available and pause if the slave has not asserted tready yet.

 

The hardware signal screenshot you attached looks reasonable. Since you're now seeing data in memory but an error message, we should probably focus on the software. What are you setting as the transfer 'length' ? Is it greater than or equal to the number of beats in hardware that you're transferring? Is the destination address correct?

 

Can you post a dump of your DMA registers before and after you kick it off by writing the length register?

www.xilinx.com
0 Kudos
Highlighted
Visitor
Visitor
11,170 Views
Registered: ‎08-27-2015

There is something I don't understand about the AXI DMA IP : is that normal that the TREADY signal is set to 1, even before I kick off any transaction ? 

 

To answer your question : before any transaction, my DMACR register is 0x00010003 and my DMASR register is 0x00000000, which seems normal to me. After setting the length of the transfer, the DMACR register become 0x00010002 (so it is stopped) and the DMASR register become 0x0005011, which seems to say that i had an internal error that halted my dma engine.

 

Thanks to the ILA, I observed that the TREADY signal falls to 0 just after the TVALID signal rises up. Is that normal ? 

This is how I understand that : the TVALID signal causes the internal error, and because of that the DMA engine isn't ready anymore.

 

I use a 14 bits width buffer in the DMA engine, I tried to write in memory a lot of different lengths (8 bytes, 32 bytes, 256 bytes and 512 bytes), and the hardware send 8 32bits words each time (the TLAST rises up on the 7th word).

 

I have a last question : what are the TSTRB signals ? I don't use them and I have no idea of what they are for... 

 

 

0 Kudos
Highlighted
Visitor
Visitor
11,167 Views
Registered: ‎08-27-2015

I forgot : the address I use is the address of an array of integers defined like :

 

int dma_buf[DMA_XFER_LENGTH];

 

I start the memory write by settings the to registers (direct address and length) like this :

 

Xil_Out32(DMA_BASE_ADDR + S2MM_DA, (u32)dma_buf);
Xil_Out32(DMA_BASE_ADDR + S2MM_LENGTH, DMA_XFER_LENGTH);

 

 

0 Kudos
Highlighted
Visitor
Visitor
16,446 Views
Registered: ‎08-27-2015

I didn't find a solution but I realized it was simpler to directly write into RAM memory using AXI HP inferfaces than using this AXI DMA IP... So we can consider this problem is solved, I have a working system.

View solution in original post

0 Kudos
Highlighted
Observer
Observer
2,910 Views
Registered: ‎03-17-2008

Just a bit of information from my experience. . . 

 

I was seeing similar behavior as the original poster. I had a little demo running previously with no problems, but then I needed to add scatter-gather management for Video4Linux2 support. Having done that, I started getting the tready signal stuck at 0 and the DMAIntErr bit was being set in the status register for the first DMA buffer.

 

The cause was this: As of Vivado 2017.1, the AXI DMA IP version 7.1 defaults to a Buffer Length Register width of 14 bits. With Video4Linux, the buffers were up to a megabyte, so when the length was loaded from a buffer descriptor, the lower 14 bits were zero, and the DMA IP thought that a zero-length buffer had been queued.

 

It seem as though the driver (xilinx_dma.c in my case since I'm using Linux) could do a test on the buffer length registers (MM2S_LENGTH and S2MM_LENGTH) to determine the maximum DMA length.

 

The solution, of course, was to set the Buffer Length Register width to 23 bits in the IP recustomization window.

 

Hope that helps someone else who might run into this issue.

 

Aric.

0 Kudos