05-18-2020 10:29 PM
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:
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:
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?
05-27-2020 03:06 AM
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.
06-11-2020 12:13 PM
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?
06-27-2020 07:36 PM
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
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."