How to handle tx_st_ready for Cyclone V PCIe

Hi corestar 

I noticed the screenshot in your post appears to be from the older and obsolete user guide (Cyclone® V Hard IP for PCI Express* User Guide). While this document may still be accessible through internet searches, it has been removed from the official Altera documentation site, see this KDB: https://community.altera.com/kb/knowledge-base/why-is-the-cyclone%C2%AE-v-hard-ip-for-pci-express-user-guide-page-not-found/347580  

To access the latest documentation, please use the following resources:

• PCIe Support Center: https://www.altera.com/design/fpga-ip/pcie-support 
  For PCIe documentation, the best starting point is the PCIe Support Center. This page consolidates PCIe user guides across all supported device families.
• Altera Documentation & Resources Center: https://docs.altera.com/

Since you are using the Avalon-ST interface, please refer to the Cyclone® V Avalon® Streaming (Avalon-ST) Interface for PCIe Solutions User Guide*. You can find the user guide link in the provided KDB, PCIe Support Center, and Altera Documentation & Resources Center.

I also noticed that the timing diagram shown in your screenshot (Figure 7-21) has been corrected in the latest user guide revision. The updated diagram provides a clearer description of the signal behavior.

Below the is the corrected timing diagram:  

To answer your question on readyLatency:

• readyLatency is not a user-selectable IP parameter in the Cyclone V PCIe IP Parameter Editor. Instead, it describes the effective handshake timing between the PCIe core and the application logic. The PCIe Hard IP drives tx_st_ready, while the application logic drives tx_st_valid and tx_st_data.  
• The user guide states that when tx_st_ready, tx_st_valid, and tx_st_data are registered in the typical implementation style, Altera recommends a readyLatency of 2 cycles to facilitate timing closure; however, a 1-cycle response is also possible.  
• In practice, this means:
  • 2-cycle readyLatency is the recommended and easier case for timing closure
  • 1-cycle readyLatency can reduce latency, but it requires a tighter ready-to-valid/data path in the user RTL and is therefore harder to meet timing.  

Additionally, the Avalon-ST specification (user guide link: https://docs.altera.com/r/docs/683091/22.3/avalon-interface-specifications/synchronous-interface?tocId=LUasgm1svG8VSQd1UQY7Aw) states that source outputs toward the sink, including data, must be registered on the rising edge of the clock, which is why the registered 2-cycle implementation is considered the typical case.

I hope this answers your questions. Please let me know if any clarification is needed.

Thanks. 
Best Regards, 
Ven Ting