cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
aherson
Contributor
Contributor
6,226 Views
Registered: ‎01-05-2012

Requester Interface Returns Error Codes Only

Hi Folks,

 

I have been migrating a legacy PCIe DMA from Virtex 5 to Ultrascale and am have simply hit a wall trying to get the Requester interface to run properly.

 

As a background, I have a fully functional PCIe IP core with PC drvier running on a Virtex 5 and have been tasked to migrate this guy forward to the Kintex Ultrascale.  The current state of my core and driver is such that I can read and write the PIO registers just fine, but I cannot request from the PC.

 

The general flow is as follows:

 

  1. The PC allocates memory at specified addresses, there are many
  2. The PC collects the addresses of the allocated memory into an other block of memory
  3. Via PIO, the PC writes to the FPGA EP the address of the other block of memory
  4. Upon receipt of the address, the FPGA EP, via the rq interface, requests from the PC RP the other block to learn the specified address list
  5. On the rc interface I received 0x40009000 which means (pg156):  1001: Request terminated by a Completion timeout. The other fields in the descriptor, except bit [30], the requester Function [55:48], and the tag field [71:64], are invalid in this case, because the descriptor does not correspond to a Completion TLP.

 

Unfortunately, I have been stuck on this for too long and simply do not know how to debug it further.  To the extent of my knowledge, I feel that that PCI Core is set in the similar manor as the Virtex 5 revision.

 

Can we start with the basics, how to know what the Function and Tag field should be?

More difficult, how to move forward on this?  What new tests can I try?

 

Thanks,

rq_error_0x9.JPG
0 Kudos
4 Replies
austin
Scholar
Scholar
6,195 Views
Registered: ‎02-27-2008

A,

 

As UltraScale is so new, it does not have as much support and debug information available.  There is the 7 series debugging guide however.  Have you attempted to follow that ?

 

Tech answer 56616

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
aherson
Contributor
Contributor
6,022 Views
Registered: ‎01-05-2012

Hi @austin

 

Thanks for the reply.  I looked over the documentation and found that the situation is still the same.

 

I am wondering if I have a link issue because my PC is only GEN2 whereas the core is GEN3.  Since PIO messages go through the cc/cq interface initiated by the PC, maybe that link is healthy (i.e. trained).  Perhaps, the core and FW are assuming that the link is GEN3 (i.e. no training) and therefore I get timeouts on the interface.

 

Is it possible?  I have no other idea.

 

Thank You,

A

0 Kudos
austin
Scholar
Scholar
5,988 Views
Registered: ‎02-27-2008

a,

 

Gen3 is supposed to be able to fall back, I agree.  Look at the documentation.  Contact your local FAE.  Check for any errata.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
chandima7
Observer
Observer
2,264 Views
Registered: ‎03-20-2009

Hi Austin,

 

I have create a pcie core project using Ultrascale Gen3 PCIe Integrated Block 4.2 version. It work well for the Memory Write requests but fail for Memory Read requests. All the parameters in both requests are identical excepts the Req Type field to set the memory reaad/write. But for memory read requests, I am getting a completion timeout TLP. I have tested this on a FPGA board using a linux driver which I have used in testing the earlier generation (gen1) PCIe core transactions. Below is the Vivado Hardware Manager results window. Can you provide some guidance on this please?

 

 

Completion Timeout.PNG

 

Thanks in advance.

0 Kudos