FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5988 Discussions

P-tile PCIe what if is rx_st_ready_i deasserted?


If the application deasserts rx_st_ready_i, what does this mean for the endpoint behaviour regarding the TLPs that are inbound towards the FPGA? Will these TLPs be dropped in PCIe core?


I.e. is it even allowed to deassert rx_st_ready_i for a well-behaving PCIe endpoint?


P-Tile Avalon Streaming Intel FPGA IP for PCI Express User Guide, 4.4.2. Avalon-ST RX Interface

UG-20225 | 2021.07.06


0 Kudos
2 Replies


You can find the explanation of rx_st_ready_i signal in user guide doc (page 57)

Pls see my reply below.

  1. If the application deasserts rx_st_ready_i, what does this mean for the endpoint behaviour regarding the TLPs that are inbound towards the FPGA? Will these TLPs be dropped in PCIe core?
  • If rx_st_ready_i is deasserted by the Application Layer on <n> cycle , the Transaction Layer in the PCIe Hard IP continues to send traffic up to <n>+ readyLatency cycles after the deassertion of rx_st_ready_i. P tile ready latency is 27 clk cycles.
    • You can refer to further explanation and timing diagram in chapter 4.4.3. Avalon-ST RX Interface rx_st_ready Behavior (page 62)
  1. is it even allowed to deassert rx_st_ready_i for a well-behaving PCIe endpoint ?
  • The answer is YES but not recommended. Ideally to achieve the best performance, the Application Layer must include a receive buffer large enough to avoid the deassertion of rx_st_ready_i
    • This is just extra back pressure mechanism available for the application host to use if they need to

In short, when application layer deassert rx_st_ready_i, P-tile hard IP will gradually stop transferring TLP packet back to host and it will resume the packet transfer once rx_st_ready_i is asserted back





Thank you for your answer, however I do not find the answer clear.


All the points you mention are in the documentation, and I have read the documentation.


However, the last sentence you suggest you are summarizing the documentation "In short, ..." but you are coming up with a new fact: the hard IP will stop transferring TLP packets back to host.


So you are suggesting when I disable the inbound direction (Root Complex to FPGA) the Hard IP will stop transferring TLPs upstream (towards Root Complex) also? This is not documented.


What happens to the inbound traffic (Root Complex to FPGA) when I deassert rx_st_ready_i? Will these TLPs be dropped inside the Hard IP?