03-07-2017 03:27 AM
I am testing a very simple design using an AXi-DMA to transfer the value of a counter in main memory. I observed two strange (for my point o view) behaviours of the tready signal of the S2MM axi stream slave port of the AXI-DMA. The AXI stream master is a simple counter feeding count in the S2MM stream interface. The handshake is controlled using tvalid (driven by the counter) and tready (driven by the axi-dma). So my questions are:
1) after reset, the tready signal is high, even if the dma has not been programmed yet. If I start the counter before programming the DMA I can observe 4 data transfer (tvalid = 1 and tready = 1) before tready goes to 0. After programming the dma the transfer resume, but the priovious 4 data were lost; why tready goes 0 after 4 clock cycles with tvalid = 1 ?
2) let assume the counter is programmed to issue 100 cycles to the dma S2MM interface; and assume that I program the DMA to transfer only 50 cycles; after 50 cycles the dma stop transferring data but tready remain at a level 1 for some cycles more; in this case the counter continue to feed cycles inside the dma queue; but when I restart the dma, the first data trasferred is not the 51st cycle, but the value at which the counter effectively sample tready = 0; while tready goes 0 not immediately after the dma finished its transfer ?
Thank you very much for your help.
03-07-2017 06:52 AM
This is discussed quite a lot in these forums. You might try a search for more in-depth discussion on it.
In short, the behavior you observe is correct as the DMA is designed. Your counter shouldn't be dependent on tready from the DMA.
I'd start here:
03-08-2017 05:42 AM
Thank you very much bwiec.
I surfed the forum and analyzed the sample you suggest. But I was not able to find the correct answer. As long as I understand, there is an hardware handshake (as described on the documentation) on the stream channel of the axi dma. The master (the counter) start the transfer asserting tvalid. On the next clock edge tready is inspected. If asserted high, that transfer has been consumed by the PS. If asserted low the transfer has not been taken place and should stall until tready is high again. In the design you suggest, there is an Axi fifo that manage that handshake But it is not clear to me how to use that handshake. For example, after the hw reset (when DMA has not been programmed yet) Tready is high. And will stay high until 4 transfer has taken place. Then, it goes low. Using the xilinx driver, for example, during the DMA programming, tha DMA core is resetted. And, to be in touch with the previously example, the four data transmitted will be lost during reset. So, what is the correct use of the Tvalid/Tready hardware handshake ?
Thank you so much for your help.
03-08-2017 05:54 AM
The driver only resets the core on initialization. Data that comes in prior to that is probably invalid anyway so flushing it is okay. Any transfer thereafter won't reset the core.
In your example, there's an implicit dependency between the counter and the software so you need to take the right steps to manage that. If your counter should not send data (i.e. assert tvalid) until software has kicked off the DMA and is ready to go, then you need some logic and communication to software to accommodate it.
03-08-2017 06:37 AM
Ok. That's clear to me. I have a further question moreover. Let us consider that the counter is a free running counter able to increment itself only when Tready is high. Suppose I would like to transfer 10Kbytes sample to main memory. I will program the Axi-Dma to transfer 10KBytes. That's ok. But it looks like I will write such a limit also into my custom logic to stop the counter and gracefully close the transfer using Tlast (Custom Logic -> DMA). If I do not provide that, the DMA signals "Internal Error" and it is no longer usable until I reset it. My hope was that, in such a case, Tready could be used to temporarily stop data transfer until the DMA core will be programmed again. Tready, effectively, goes low, but only a small amount of data transfer that will be lost due to the reset condition following internal error. So have I to duplicate the length of the transfer inside the PL (Custom Logic -> The counter) to be sure the transfer will be closed gracefully ?
Thank you so much.
03-08-2017 06:59 AM - edited 03-08-2017 07:00 AM
Yes, the way the AXI DMA is designed, you must assert tlast less than or equal to the number of bytes that the software has told it to transfer. I understand this is an inconvenience, but the reality is that the core was designed to work with data that's well defined into packets. When you use a purely streaming data source, you have to break it up into packets when interfacing to the DMA. This is done by tlast.
Once you're more comfortable with the core, there's something called Cyclic BD mode which could be used and is more natural for streaming sources. This could potentially be used to eliminate tlast requirement, but it costs some additional logic to enable the SG interface so it may or may not be worth it depending on your actual use case.
09-27-2017 05:51 AM
Hi Marco Bisio,
Did you find a solution for your problem? I've got the same problem as you pointed when" tready goes 0 after 4 clock cycles with tvalid = 1". I simulated my DUT using AXI Verification IP and there is no handshake problems. There are so many discussion about that but they didn't help me.
04-19-2018 11:40 AM
I have the same issue here. tready goes low after 4 clock cycles when tvalid goes high. I am using tlast_gen IP core that connects to S_AXIS_S2MM of axi_dma. I have gone through the forums but have not found the the solution. Also, in the link: https://www.xilinx.com/support/answers/57550.html, I don't see the hardware design example. Can anyone help?