cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
355 Views
Registered: ‎06-25-2018

PCIe DMA streaming AXI c2h transfer data throughput problem

When I send data with and AXI stream from c2h with the PCIe IP core the TREADY signals keeps going low longer and longer which eventually it can’t keep up with the data. Below is an image of the ILA  captured:

PCIe_DMA_waveform_1.JPG

Also the status bits 1/4/5 are going high during the transfer which I don’t see when I run the loop back example. These status bits always go high after I send a certain number of data no matter how much the data is spaced.
When I look at loop back example only bit 3 goes high and at the end when TLAST is high all the status bits go high:

PCIe_DMA_ex_waveform_2.JPG

I configured my IP core the same as the loop back example and use the same example C code provided. What could be the issue?
Thanks,
Daniel

3 Replies
Highlighted
Xilinx Employee
Xilinx Employee
247 Views
Registered: ‎08-02-2007

回复: PCIe DMA streaming AXI c2h transfer data throughput problem

one difference between your design and loopback example is that the loobpack's throughput is depends on the h2c's speed.

So could it because the example have lower c2h throughput than your design?

The tready usually be deasserted because of the backpressure from the host. If this is the case , the driver will have problems to read the status/control registers because the completion are all blocked by the eariler C2H data and it will result to other issues.

 

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
153 Views
Registered: ‎06-25-2018

回复: PCIe DMA streaming AXI c2h transfer data throughput problem

Yes, I agree the loop back example has lower throughput than my application. But my data stream has a maximum data rate of ~5GB/s which should be well be below the throughput specification of a 16x lane gen 3.0 PCIe capability, which is listed at 15.75GB/s.

Why can't it handle the data throughput, I'm using 4 x AXI data streams?

Also who sets the status signals xdma_0_c2h_sts_0, the host or card?

And what does status signal "5: IRQ event pending" mean?

Thanks, Daniel

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
80 Views
Registered: ‎08-02-2007

回复: PCIe DMA streaming AXI c2h transfer data throughput problem

 

For your questions :

1 . The performance in AR65444 shows the performance is  about 80%  and it varies for different reason what could be checked for the reason of Lower than expected performance is seen

  •  Check the Link Status in lspci to ensure that your link is coming up to the full speed and width                                                                   
  • Check Max Payload Size and Max Read Request Size using lspci. Some systems might only support 128 Byte transfer which will be slower than 256 Byte or 512 Byte capable systems
  • Generally, larger transfer per descriptor will result in higher performance, but it can also be caused by system limitations or AXI peripherals behind the XDMA IP.
  • check if the outstanding/thread value if the XDMA core is the same as the AXI  slave port settings . In IPI design , the tool will  make all the parameters compatible but if the XDMA RTL design is used, user need to guarantee the parameters are set correctly

Usually the performance reduce is caused by the host,using the example design with AR65444 is showing the estimated performance of the host.

 

2 the c2h_status is set directly by the IP core.

3 the IRQ pending  could because the user _irq_req  is still high or the host has not serve the earlier interrupts ,  this is from PG195

"The user logic must hold usr_irq_req active-High even after receiving usr_irq_ack (acks) to keep the interrupt pending register asserted. This enables the Interrupt Service Routine (ISR) within the driver to determine the source of the interrupt. Once the driver receives user
interrupts, the driver or software can reset the user interrupts source to which hardware should
respond by de-asserting usr_irq_req."

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos