Why does the Arria II GX transceiver CDR, configured in automatic locked mode, keeps the rx_freqlocked signal asserted in any other mode except PCIe mode?

You may observe rx_freqlocked signal stuck high/asserted position due to CDR lock issue caused by a software bug in Quartus II 10.0 SP1 and earlier versions.  This issue could be observed in all modes, except for PCIe mode.  SAS/SATA or applications using rx_signaldetect signal may need additional workaround.  Please, click here for SAS/SATA workaround.

For an explanation of why the Arria® II GX CDR unit may be keeping the rx_freqlocked signal asserted in any other mode except PCIe mode, refer to the Arria II GX Errata Sheet (PDF).

To workaround this issue, download and install the appropriate patch from the links below.  The software solution to resolve this problem is fully integrated into the Quartus II software versions later than 10.0 SP1, hence no patch is required in a later software version.

Note that the software patches are not compatible with certain previous patches indicated below.  If you are using one of these incompatible patches, review the alternate solution involving the reset sequence illustrated in Figure 1 and described below, or file a service request at mysupport.altera.com if yu require a compatible patch.

• Quartus II software version 9.1 SP2 (Patch 2.109 is not compatible with patches 2.17, 2.35, 2.76, 2.77, 2.78, 2.83, and 2.98)
• Download the Quartus II software version 9.1 SP2 Patch 2.109 for Windows (.exe)
• Download the Quartus II software version 9.1 SP2 Patch 2.109 for Linux (.tar)
• Download the Readme for the Quartus II software version 9.1 SP2 Patch 2.109 (.txt)

• Quartus II software version 10.0 SP1 (Patch 1.158 is not compatible with patch 1.151)
• Download the Quartus II software version 10.0 SP1 Patch 1.158 for Windows (.exe)
• Download the Quartus II software version 10.0 SP1 Patch 1.158 for Linux (.tar)
• Download the Readme for the Quartus II software version 10.0 SP1 Patch 1.158 (.txt)

After installing the patch, you can just re-run the Quartus II software assembler without the need to perform a full compilation.

Alternate Solution  <<Bold>>

As an alternative to above software solution, you can apply the reset sequence solution described below as

illustrated in the waveforms in Figure 1 to resolve the problem.

Figure 1. Reset Sequence Waveforms

Note (1): if you are not using rx_signaldetect signal, ignore the 64k parallel clock cycle timing and refer only to the steps below. 

1. Assert the rx_analogreset and the rx_digitalreset signals.
2. The rx_freqlocked[0..n-1] signals will go low, indicating that the transceivers are locking to the reference clock (lock to reference).
3. Deassert the rx_analogreset signal. Ensure data is present at the receiver inputs before deasserting the rx_analogreset signal.  If you are using rx_signaldetect port, you can follow the timing diagram as suggested above. If you are not using the rx_signaldetect signal, refer to special note below on how to detect the presence of data at your RX buffer. For more information on this, you can refer to solution rd02012011_970.
4. The rx_freqlocked[0..n-1] signals will go high, indicating the transceivers are locking to data.
5. About 4 µs (t_{LTD_Auto}) after the last rx_freqlocked signal goes high, deassert the rx_digitalreset signal.

Special Note

Use one or more of the following methods below to identify if data is present at the RX buffer.

1. Signal detect is available in PCIe and Basic modes.  You can monitor rx_signaldetect signal as loss or presence of link indicator. rx_signaldetect will assert, if there is valid data present at the RX buffer.
   
2. You can implement a PPM detector in device core for modes that do not have signal detect to monitor the link. PPM detector will help you identify if there are valid data present at the link or not.
   
3. Data corruption or RX phase comp fifo overflow/underflow condition in user logic may indicate a valid or invalid data at the RX buffer.