readyLatency of Arria 10 PCIe Avalon-ST IP - readyLatency of Arria 10 PCIe Avalon-ST IP Hello, I'm writing a design with Arria 10 AVST PCIe IP (Quartus 22.4; PCIe IP version 20.1.1). The SoC is written in verilog rather than Block Design to promote portability. So we need to handle readyLatency ourself. Also, we use custom 250Mhz clock `soc_clk` to drive `pld_clk` rather than default `coreclkout_hip` to avoid CDC. And I have encounterd a weird problem regarding ready & valid handshake of AVST interface on the RX path. Basically , using SignalTap, I saw AVST's valid asserted by the IP after two cycles when ready is asserted, recovering from a backpressure on the RX path. According to AvalonST Spec, valid can only be asserted on ready cycles (n + <readyLatency>). So I believe this implies a readyLatency = 2 on RX path. But after I checked the pcie_ep.xml , which I believe is a document regarding current IP settings. And I saw readyLatency on both RX and TX path is 3. So I checked PCIe IP's User Guide (version 18.0, latest on website), and it says that RX path has a readyLatency of 3, but for TX path, it has a readyLatency of 2. Based on my obverstaion, I'm very confused now. What is the actual ready latency for these path? Is there a reliable way that I can confirm for each IP generation? Replies: Re: readyLatency of Arria 10 PCIe Avalon-ST IP Hi Chenyang, Thank you for your confirmation. I am glad that your questions have been addressed. With that, I will transition this thread to community support. If you have a new question, feel free to open a new thread to get support from Altera experts. Thanks. Best Regards, Ven Replies: Re: readyLatency of Arria 10 PCIe Avalon-ST IP Hi ventt, Thank you for handling this case. I now understand the handshake paradigm of avalon stream. Replies: Re: readyLatency of Arria 10 PCIe Avalon-ST IP Hi Chenyang, May I know if you have any further questions about my previous message? Thanks. Best Regards, Ven Replies: Re: readyLatency of Arria 10 PCIe Avalon-ST IP Hi Chenyang, Thank you for sharing your detailed observations regarding the signal behavior of rx_st_ready and rx_st_valid. You are right about the current IP settings in which both the RX and TX path has a readyLatency of 3. I observed the same from our Design Example generated from Quartus. According to the User Guide, when it mentions a ready latency of 3 cycles, it does not mean the readyLatency must be exactly 3 cycles. Instead, it means the readyLatency can be up to 3 cycles. The user's Application Layer should be designed to handle the readyLatency up to the specified number, which is 3 in this IP. Another way to check your readyLatency is via Quartus Platform Designer. 1. Open the .qsys file. 2. Go to View > Component Instantiation . 3. Locate the Arria 10/Cyclone 10 Hard FPGA PCIe IP . 4. Under Component Instantiation tab > Signals & Interfaces sub-tab > click rx_st signals. 5. You should be able to see the Ready latency value configured. Arria® 10 and Cyclone® 10 GX Avalon® Streaming Interface for PCI Express* User Guide: https://www.intel.com/content/www/us/en/docs/programmable/683647/18-0/datasheet.html I apologize again for my late response. I hope this has clarified your questions regarding the readyLatency of this IP. Please let me know if anything remains unclear. Thanks. Best Regards, Ven Replies: Re: readyLatency of Arria 10 PCIe Avalon-ST IP Hi Chenyang, My apologies for missing your forum post. Please allow me some time to investigate, and I will get back to you in 1-2 days. Thanks. Best Regards, Ven Replies: Re: readyLatency of Arria 10 PCIe Avalon-ST IP Bump this thread a bit since 10 days have gone. Currently after checking example design exported from Quartus, we tried to implement our Application Layer that are capable receiving more than 3 beat of data after ready=0 on RX side (readyAllowance>3), and never assert valid=1 when ready=0 on TX side (readyLatency=0). For now I believe it works and I never saw garbage TLP from HIP, which I believe is an internal buffer overwrite due to incorrect readyLatency. The documentation is still unclear. If possible, please check and clarify the readyLatency of this IP. Thank you very much.