Correct Arria II GX ALTGX Reset Sequence?

I also tried the reset sequence described on page 4-13 in the Arria II GX handvook, Vol2. This keeps rx_digitalreset asserted until 4us after the CRU has locked to the data and rx_freqlocked asserts (automatic lock mode). The outcome is the same; pipestatus=4 (8b/10b decode error).

Updated files attached.

Any idea what to look for?

We just had an Altera transceiver specialist in this last week and his recommendation with respect to resets was that rx_digital_reset should only be released after rx_freqlocked has remained high for 4us. In my opinion this is not very clear in the sequence diagrams but if you signaltap the pins you can see that rx_freqlocked toggles for a while once it goes active. The Altera guy said that it rx_freqlocked to be continuously asserted for 4us before releasing rx_digital_reset.

There's also a specific reset sequence for PCIe functional mode http://www.altera.com/literature/handbooks/wwhelp/wwhimpl/js/html/wwhelp.htm#href=stx4_siv52004.21.3.html

That was for stratix iv but maybe something similar for the ArriaII part?

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!

NOTE: When connecting the FPGA inputs directly to the motherboard slot (via a converter board) I still get pipestatus 4 (8b/10b decoding error). Since this is directly connecting the Arria II GX to the motherboard without any buffers inbetween it must mean something is not working correctly with the FPGA configuration.

Note that the transmit pins are not connected, only the receive pins.