TLP Status query

Comments and questions related to the "Down to the TLP" pages

TLP Status query

Postby Guest »

Hi Eli,
Your Blog is very useful to understand PCIe for beginners. I have a question regarding monitoring the TLPs sent by the fpga to the host(root port). Can we find out whether the TLPs are correctly received by the rootport after the memory writes are sent from the fpga side, in Linux specifically?
Thanks!
Guest
 

Re: TLP Status query

Postby support »

It's a tricky issue. lspci -vvv tells you about the error flags of each device, including errors regarding receiving bad packets, but I'm not sure where to look for errors in packets to the root port.

The simplest way to know that a memory write packet arrived is to check if the memory was indeed changed. There is no cache coherency issue on PCs. It's when it fails, that it becomes a bit difficult to tell why. There are traffic analyzers for that (pretty expensive), but I never needed to deal with those things. Trial and error is most likely the best way to solve problems like that.
support
 
Posts: 802
Joined:

Re: TLP Status query

Postby Guest »

Hi Eli,

Thanks for the reply! Actually, I am facing such an issue. I have sent Memory Writes to the host but only the first packet is correctly received and the rest of the memory is not unchanged. It is very hard fro me to find the rootcause of this problem. I am sending 32 length TLPs, same as that sent by you and seen in the sniff dump. It's hard to understand why only the first TLP is received and not the following ones, as they are created in the same way. Thanks!
Guest
 

Re: TLP Status query

Postby Guest »

Sorry! There was a typing mistake.
*The rest of the memory remains unchanged.
Guest
 

Re: TLP Status query

Postby support »

The question is if those packets were transmitted at all. Maybe something in the logic went wrong (for example, maybe the second packet was submitted to the FPGA logic before it was ready to accept it?).

I solve these situations with trying just random things: Inserting large delays between the packets (possibly writing to the same address), changing the address of the first packet, changing whatever. A few backs and forths, and the reason soon reveals itself. Once you have the first packet through, it's relatively easy to figure out why the next ones don't appear.

Good luck!
support
 
Posts: 802
Joined:


Return to General PCIe

cron