Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎06-22-2011

About the logic for tready signal for PCIe DMA and xdma driver

Hi all,

I am using the Xilinx PCIe DMA IP and xdma driver in Windows 7.
The DMA IP is configured for axi stream mode.
In the example design, the H2C axis master is connected to the C2H slave.
I can test the design with the following steps:
1. In a console window, ran this command to read from C2H channel:
xdma_rw c2h_0 read 0 -l 0x1000
Because there is no data to feed C2H channel, the reading was blocked
2. In another console, ran this command to write data to H2C channel:
xdma_rw h2c_0 write 0 -b -f data.bin
Then the reading and writting completed as expected.

But I got problems to use this IP in my design.
In my application, I had a data stream with constant rate of data ( maybe
from ADC ). I want to get any length of data from the stream when I issue
a FileRead with the length specified. For the FPGA logic, I don't know
how many bytes the software will want. Hence, there is no tlast for C2H
channel. Is this acceptable for the IP?

I also noticed something really confusing: when I stepped through the
xdma_rw program, the tready signal went high right after the CreateFile
function call. In my application, since the data source was ready before
the running of xdma_rw, then my data went through C2H channel continuously ( never stopped ).
Since the FileRead opration was not ran yet, where did those data go?
Wouldn't it be more reasonable for the tready to become active after
FileRead function call?

best regards


0 Kudos
2 Replies
Xilinx Employee
Xilinx Employee
Registered: ‎07-26-2012

Although I'm not sure whether it is the same as this problem, it was found a problem of DMA transfer in Vivado 2017.3.


Can you try the patch if you use Vivado 2017.3 or 2017.4?




0 Kudos
Registered: ‎07-22-2018

I am seeing the same issue with the Vivado 2018.2 Windows 10 64-bit firmware/software.  After the CreateFile() function is called for the C2H stream channel, s_axis_c2h_tready and c2h_sts[6] (control register 'run' bit) both go high immediately.  This messes up my data transfer because I have to set s_axis_c2h_tvalid high via a register write before calling ReadFile().


Should the correct behavior be that tready goes high after ReadFile() is called, not CreateFile()?


I didn't see any patches for 2018.2.


Thanks for any help!

0 Kudos