UPGRADE YOUR BROWSER
We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!
07-08-2018 08:43 PM
HI,
Basically I am trying to understand how the DMA/Bridge functions and what I have to do to interface to the C2H AXI-Stream port. So I put together a block design with the DMA/Bridge, couple of AXI-Lite peripherals (BRAM controller, timers, I2C), two loopback streaming FIFO and my custom RTL block wired into a FIFO then to the AXI-Stream switch. I have the AXI-Stream switches configured for user configuration. The attached PDF is the block diagram in PDF form.
I believe I have my stream generator correct and then correctly configured to work with the DMA engine.
tkeep is tied high, tlast is high for one clock cycle on the tvalid after 128 beats (128 beats * 32 bytes = 4096 = transfer size in console) has passed. Below is a xsim screenshot showing the timing after 256 beats (8192 byte transfer).
xsim_axis_gen_type0.PNG
The idea with the data generator is to slow the data rate down to what I am expecting, 125MB/s to 250MB/s and to keep track of samples.
That hopefully gives you the idea on the firmware side. Software side, I started using the the new Linux driver and enabled debugging which worked instantly and great for the loop back tests. I have a script the configures the data routers before running running the dma_to_device and dma_from_device. This works up to the size of the largest FIFO (512kB). So I don't think it has anything to do with the driver or software I have written. When I switch over to my axi stream generator I have all of the parts form the dma_to_device and dma_from_device in a script that I call. The script configures the data routers, simulator, enables the simulator then asks for data. I ensure that the number of bytes I am asking for matches the number of bytes between tlast pulses.
Using the new Linux driver I get an immediate return value of -1 from the file read() call (my script and dma_from_device give the same thing). Also the driver is in poll_mode, using interrupts would hang. Going to the old Linux driver it changes a little bit in that I will get 29 bytes.... I am not sure what has changed in the background of the driver.
dma_from_device_console_output.png
That screenshot is with the old Linux driver.
Another difference between the drivers is the amount of dmesg output when debugging is enabled. The new driver output nothing when running dma_from_device. The old driver would actually say:
xmda:complete_cyclic: 0-C2H-ST result[0] length 0x1d
So it seems the DMA engine thinks it finished the transaction when it is being polled. When the driver is installed to use interrupts it just hangs. I don't know enough why it would do that. I am just looking to figure out what I am doing wrong and where.
New driver : Xilinx_Answer_65444_Linux_Files_rel20180420.zip
old driver: Xilinx_Answer_65444_Linux_Files.zip
Other info:
Vivado 2016.4 on Windows 10
Ultrascale 115 card running in an Ubuntu 16.04 computer
DMA/Bridge 3.0
Gen2.0 x8 lane endpoint
My References:
https://www.xilinx.com/support/documentation/ip_documentation/xdma/v3_0/pg195-pcie-dma.pdf
https://www.xilinx.com/support/answers/65444.html
https://forums.xilinx.com/t5/PCI-Express/DMA-Subsystem-for-PCIE-axi-stream-C2H-transfers/td-p/746740
https://forums.xilinx.com/t5/PCI-Express/PCIE-DMA-subsystem-AXI4-Streaming-c2h-transfers/td-p/791701/highlight/true/page/2
https://forums.xilinx.com/t5/PCI-Express/DMA-Bridge-Subsystem-for-PCIe-AXI-Stream-c2h-interface/m-p/815172#M9553
https://forums.xilinx.com/t5/PCI-Express/PCIe-streaming/td-p/812679
I feel like I am missing something simple. I am going to try and put the FIFO's into packet mode and see if that makes a difference. I am not sure why it would make a difference though.
Dark Tyr
07-12-2018 02:49 PM - edited 07-12-2018 02:51 PM
My problem has been fixed and was related to using tkeep versus tstrb. The DMA/Bridge subsystem product guide never mentions tstrb and instead only mentions tkeep (v3.0 and v4.0). This does contradict what is stated in the AXI Reference Guide:
https://www.xilinx.com/support/documentation/ip_documentation/ug761_axi_reference_guide.pdf
Which states that tkeep should be absent and that tstrb is optional/used. It may be more related to how the Xilinx IP blocks handle tstrb and tkeep (Xilinx FIFO and Xilinx Stream Switch).
The reason for the odd number of bytes being returned was that it was getting tlast and tvalid but never any valid bytes.
I now use tstrb to interface to the Xilinx FIFO instead of tkeep and leave it on auto as well as the stream switch on auto.
Dark Tyr
07-12-2018 02:49 PM - edited 07-12-2018 02:51 PM
My problem has been fixed and was related to using tkeep versus tstrb. The DMA/Bridge subsystem product guide never mentions tstrb and instead only mentions tkeep (v3.0 and v4.0). This does contradict what is stated in the AXI Reference Guide:
https://www.xilinx.com/support/documentation/ip_documentation/ug761_axi_reference_guide.pdf
Which states that tkeep should be absent and that tstrb is optional/used. It may be more related to how the Xilinx IP blocks handle tstrb and tkeep (Xilinx FIFO and Xilinx Stream Switch).
The reason for the odd number of bytes being returned was that it was getting tlast and tvalid but never any valid bytes.
I now use tstrb to interface to the Xilinx FIFO instead of tkeep and leave it on auto as well as the stream switch on auto.
Dark Tyr