12-02-2018 05:54 PM - edited 12-02-2018 06:01 PM
I am having a strange issue with the AXI DMA 7.1 IP. and the streaming to memory mapped interface. Like many people I've found my TREADY to drop low permanently but none of the causes appear to be applicable to myself. If I've missed the thread that solves my issue please point me to it, but I did search!
Please note I'm not driving data into the DMA engine before I've configured it. I've setup a long descriptor chain, and my packet sizes are shorter than the any of the buffer lengths. TREADY goes low somewhat randomly. It's always in response to recent data. However It can happen anywhere after several hundred and several thousand data beats . My packets are currently 16384 bytes or less and the buffer sizes are 1 megabyte. The exact rate at which the DMA is supplied data is a bit chaotic, but it's very bursty. The status registers have none of the error flags set including the 0 length flag. After TREADY goes low the engine is unrecoverable. Writing the reset register bit doesn't help. The bit never clears itself like it would under normal operations. None of the master AXI interfaces are stalling it, so it's not waiting on the outside world to write data or update descriptors. Near as I can tell it's in an invalid state and nothing I've found explains it or can fix it. Any help would be very much appreciated!
IP Settings: Generated in 2018.2 and includes Scatter Gather and a 26 bit length register. Let me know if any other relevant settings are required.
12-10-2018 03:17 PM
When I have seen AXI DMA react this way, it is usually because of larger problems in the system. Sometimes there's a bad master that prevents the M_AXI_S2MM writes from completing. These are "interesting" problems to sort out. Do you have any custom AXI master IPs in you system?
The way to start looking for these sorts of issues is to add AXI Protocol Checkers and System ILAs on the memory mapped interfaces. You'll need to think about where blockages could occur; this is usually on the MI side of the AXI Interconnect that is downstream from the AXI DMA. The stand alone Protocol Checker has some options in its configuration GUI to enable triggers on maximum number of idle cycles between AWVALID and AWREADY (for example). The Protocol Checker that is integrated into the System ILA does not have support these trigger on timeout features.
The monitor that was helpful in a previous debug is the "Maximum number of idle cycles for WVALID monitoring after AW command." Set it to something like 1024. A well behaved master should send its write data within a few clocks of sending the AW command. You'll need to hook up the Protocol Checker outputs to an ILA to see if it triggers.
Some other things to look at:
Have you looked at the Scatter-Gather interface to see what is happening there? If this interface gets blocked by other masters, it will also lock up the AXI DMA.
Can you tell if all of the stream data received before TREADY drops gets forwarded to the memory mapped side?