Article ID: 000082823 Content Type: Troubleshooting Last Reviewed: 04/25/2018

Why does the Intel® Hard IP for PCI Express* in Gen3 configurations, periodically transition from the L0 LTSSM state to the Recovery state then back again?


  • Arria® V GZ FPGA
  • Intel® Arria® 10 FPGAs and SoC FPGAs
  • Stratix® V FPGAs
  • Quartus® II Subscription Edition
  • Intel® Arria® 10 Cyclone® 10 Hard IP for PCI Express
  • Arria® V GZ Hard IP for PCI Express Intel® FPGA IP
  • Avalon-MM Stratix® V Hard IP for PCI Express Intel® FPGA IP
  • Stratix® V Hard IP for PCI Express Intel® FPGA IP
  • Stratix® V Hard IP for PCI Express with SR-IOV Intel® FPGA IP
  • V-Series Avalon-MM DMA for PCI Express

    Critical Issue


    The Intel® Gen3 Hard IP for PCI* Express instance may transition from L0 to Recovery and back again if the receive(RX) Physical Coding Sublayer(PCS) receives data that is identical to a SKP or SKP END pattern.  The PCS block synchronizer will incorrectly interpret these as valid SKP Ordered-Sets and re-align the data. This results in the data block boundary being corrupted.  This will not cause data to be lost because the affected data will be re-transmitted after the LTSSM returns to the L0 state.

    The signature of this event on the PIPE interface is as follows:
    ·         The PIPE rxdata of the affected lane matches the SKP data pattern (AAAAAAAA, AAAAAAAA) or SKP END pattern (AAAAAAAA, XXXXXXE1).
    ·         The PIPE rxvalid signal of the affected lane de-asserts until the LTSSM recovery event ends.
    ·         The PIPE rxstatus signal of the affected lane reports 3’b100 (decode error or disparity error).

    It is rare that scrambled data will exactly match a SKP pattern or SKP END pattern.   Some systems may see this occur once every few hours. This issue has negligible effect on the link bandwidth.


    There is no scheduled workaround or fix for this issue. No action is required. 



    All postings and use of the content on this site are subject to Terms of Use.