02-03-2017 12:30 PM
First some background. I am attempting to use the AXI datamover as an AXI-Stream to DRAM interface. I want to be able to put data from 16 AXI-Streams into ram at unique addresses and access them at some later time, much like a variable-depth FIFO or a circular buffer where the read and write pointers are some fixed distance apart. To do this, I have created an IP block that accepts AXI-Stream data and communicates with the datamover to send the data to memory.
The problem I am currently experiencing is that the datamover will appear to accept 9 commands and 9 beats of data before holding tready low until the system is reset again. I am currently presenting data and commands at the same time. Fearing that may be the issue, I modified the code to wait to present the data until the datamover indicated it had posted the address on the AXI bus. This signal never came and the command interface would read approximately 7 commands before holding tready low and not taking any more commands. The data was never indicated as vaild, so no data beats were transmitted.
Any insight is greatly appreciated. All information has been gathered using ILAs through Vivado 2016.3. The development platform I am using is the Digilent Arty board. Please let me know if there is further information that would be helpful for you to better understand the problem.
02-03-2017 02:44 PM
@jlimbocker If I remember correctly DM has a status output stream and if you don't consume it, it won't accept any more inputs. Make sure you drain the status output.
02-03-2017 03:10 PM
02-06-2017 02:11 PM
Upon further inspection, it appears that I am receiving status packets at approximately one half the rate of incoming data. The status packets are arriving about 869 bus clocks apart while the commands are being sent about 434 clocks apart. The probe data is below. The status interface is on top and the command interface is on bottom.
While this seems to explain the problems I have been having, it does not make much sense why this would be the case. Shouldn't the latency from command to status be on the order of 30-40 clocks? The delay between the two in the images above is around 44 clocks, but this is assuming that there is a missing status tvalid.
Does anyone have any ideas?