New ContributorHi,
Your understanding is correct, is there anything else you not understand and I can clarified more ?
Regards,
Wincent_Intel
Regular ContributorHi,
1. Does the enable PCIe receive queues (P,NP,C) in bypass modes and handle flow control?
The credit interface is used to implement flow control for the data movement between the user application interface and each IP block. Each header type (P,NP,CPL) and data type (P,NP,CPL) has an independent credit interface. One data credit consists of 16 bytes. One header credit includes the TLP Header, 1DW prefix (if present) and the digest (if present).The 4.4.1.2.2. Credit Initialization
describes the credit initialization and update flow.
https://www.intel.com/content/www/us/en/docs/programmable/683501/21-4-4-0-0/tlp-bypass-mode.html
2. If so, is PCIe ordering rules for relaxed ordering implemented at the output of the receive queues before the TLP is passed on to the application layer?
the relaxed ordering Implemented on the RX side. This feature is always active. On the TX side, reordering is done by the application.
Let me know if this answering your question.
Regards,
Wincent_Intel
New ContributorHi,
Thanks for the quick reply.
I am referring to F-Tile Avalon® Streaming Intel®
FPGA IP for PCI Express* User Guide Updated for Intel® Quartus® Prime Design Suite: 22.4
IP Version: 8.0.0.
Section 3.3.2.1 says that RX flow control interface is optional and disabled by default in the IP GUI. Does the IP expect the application to maintain separate queues for data and headers for P,NP and C TLPs?
Is there a single flow control interface? If Relaxed ordering is implemented, NP and C TLPs cannot pass posted TLPs. So, why is the IP expecting separate flow control credits for the TLP types?
Thanks
Regular ContributorHi,
Does the IP expect the application to maintain separate queues for data and headers for P,NP and C TLPs?
>>The RX flow control interface is optional and disabled by default, meaning that the IP does not require the application to provide flow control credits for incoming TLPs.
Is there a single flow control interface?
>> if the RX flow control interface is optional and disabled by default, it suggests that the IP does not provide a dedicated flow control interface for each TLP type.
If Relaxed ordering is implemented, NP and C TLPs cannot pass posted TLPs. So, why is the IP expecting separate flow control credits for the TLP types?
>> it is important to note that the PCIe specification requires strict ordering between posted TLPs and completion TLPs. In contrast, non-posted TLPs, such as NP and C TLPs, do not have such strict ordering requirements. This means that the IP may require separate flow control credits for different TLP types to ensure that the ordering requirements are met for posted TLPs, while allowing for more flexibility in the ordering of NP and C TLPs.
Let me know if this answer your question or you need any further clarification.
Regards,
Wincent_Intel
New ContributorHi,
Thanks for the clarification. The following comment from you is not clear
>> "it is important to note that the PCIe specification requires strict ordering between posted TLPs and completion TLPs. In contrast, non-posted TLPs, such as NP and C TLPs, do not have such strict ordering requirements. This means that the IP may require separate flow control credits for different TLP types to ensure that the ordering requirements are met for posted TLPs, while allowing for more flexibility in the ordering of NP and C TLPs."
I am implementing relaxed ordering. With RO, non-posted (NP) and completion (C) TLPs cannot pass posted TLPs. So, if a posted TLP is next selected TLP as per RO rules, and the application has no posted credits the output should be blocked. In other words, posted TLPs cannot be bypassed even if I have credits for NP or C TLPs in the application. I agree that separate credits for NP and C TLPs may help in reordering those TLPs.
Regular ContributorHi,
Your understanding is correct, is there anything else you not understand and I can clarified more ?
Regards,
Wincent_Intel
