Correct Arria II GX ALTGX Reset Sequence?

Thank you for your reply. I have tried all possible variations of the reset sequence (PCIE vs 'non-PCIE' per the Arria II GX handbook and I still get bad pipestatus (8b/10b decoding error). I have verified that the clock and data signals have good signal integrity via oscilloscope.

I did observe that rx_freqlocked does not toggle like shown in the PCIE reset sequence in the Arria II GX handbook (same sequence as for Stratix IV). Perhaps this is because i'm only using PIPE mode and not any PCIe IP in my design?

Some background:

In my particular design, there is an external probe board that splits the PCI refclk and data from a PC motherboard into two destinations. One stream is sent downstream (to a 3rd party PCIE adapter board) and the other stream is sent to the Arria II GX (PCI Express Protocol Analyzer). The replicated signals sent to/from the 3rd party PCIE adapter works fine and I can communicate fine with it in Windows XP which indicates that the signal replication is working correctly. However, I can't get the Arria II GX to decode the data although i can lock to clock and data correctly.

I have previously used an Arria GX development board to verify that the PCIE compliance test pattern could be captured correctly when plugging in the dev board into the motherboard slot. The Arria GX QII design was pretty much the same as the Arria II GX design; the transceiver reset sequence was performed and the PIPE data was monitored via SignalTapII.

I will try to put the Arria GX board on top of my probe board to see if it is able to lock to clock and data and decode the data after the signals have gone through the probe board. Since 3rd party PCIe adapters work correctly through the probe board, the various FPGA based boards should be able to do it too.

I have one fundamental question: Is there any phase relationship requirements between the PCI Express 100 MHZ reference clock and the 2.5 GHz data signal or is it only the frequency and jitter of the reference clock that matters? I would assume the latter since the CRU should lock to the data automatically and should only use the reference clock as 'guidance'. The clock signal goes through a clock buffer on the motherboard (and on our probe board) so should not have and phase relationship with the data signals.

Thanks!