Device Family: Intel® Arria® 10, Intel® Arria® 10 GT, Intel® Arria® 10 GX, Intel® Arria® 10 SX, Arria® V GZ, Stratix® V GS, Stratix® V GT, Stratix® V GX

Type: Answers

Area: Intellectual Property

Last Modified: March 29, 2017
Version Found: v15.1 Update 2
IP: Arria V GZ Hard IP for PCI Express, Avalon-MM Arria V GZ Hard IP for PCI Express, Avalon-MM Stratix V Hard IP for PCI Express, Stratix V Hard IP for PCI Express, Stratix V Hard IP for PCI Express with SR-IOV, V-Series Avalon-MM DMA for PCI Express

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


A 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.