12-31-2014 07:11 AM
I have been looking at the PG021 v7.1, the product guide for the AXI DMA IP core. I am wondering how it handles null bytes. The DMA has the tkeep port on the AXIS bus and seems to stop working after it receives a few null bytes. There are no error messages or anything. Does anyone else have this problem? I’m wondering what the correct functionality should be?
01-05-2015 03:55 AM
I have it tied to ground (low). It ignores it but after a few beats the dma goes idle with tready going low and won’t come out of the idle state when valid data comes in. I did find this in the Datamover Product guide (PG022 v5.1) page 33.
"AXI DataMover does not support null bytes. (TKEEP completely deasserted)."
I know that the DMA block has the Datamover inside. Could this be the problem?
08-04-2015 05:30 AM
In my testing I have found that the DMA engine will forward TKEEP from the AXIS side to WSTRB on the AXI side. This means that all the data, including 'null bytes' will be moved from the streaming side to the memory mapped side but the forwarding of tkeep onto wstrb means that downstream devices know you wanted the data dropped. There is a subtlety that I forgot to check and that is whether the DMA engine counts the null bytes when calculating where the next write should occur, hopefully it doesn't count them.
08-05-2015 12:25 AM
On my opinion AXI DMA doesn't work correctly when null bytes are used as it is allowed by the AXI4-Stream specification.
When going into details, you could see AXI DMA is based on the AXI DataMover IP. For version 5.1 it's manual mentions on page 34 some limitations for null byte handling: "AXI DataMover does not support null bytes. (TKEEP completely deasserted). A start of a streaming packet is identified by TVALID while its end is determined by TLAST. AXI DataMover does not support sparse/null TKEEP between the packet boundaries. TKEEP can be sparse only at TLAST beat. TKEEP can also be sparse at the start of a packet when DRE (unaligned transfers) is enabled."