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.
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 you 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)
- Quartus II software version 10.0 SP1 (Patch 1.158 is not compatible with patch 1.151)
After installing the patch, you can just re-run the Quartus II software assembler without the need to perform a full compilation.
Note: if you are not using the rx_signaldetect signal, ignore the 64k parallel clock cycle timing and refer only to the steps below.
- Assert the rx_analogreset and the rx_digitalreset signals.
- The rx_freqlocked[0..n-1] signals will go low, indicating that the transceivers are locking to the reference clock (lock to reference).
- Deassert the rx_analogreset signal. Ensure data is present at the receiver inputs before deasserting the rx_analogreset signal. If you are using the rx_signaldetect port, you can follow the timing diagram as suggested above. If you are not using the rx_signaldetect signal, refer to the special note below on how to detect the presence of data at your RX buffer.
- The rx_freqlocked[0..n-1] signals will go high, indicating the transceivers are locking to data.
- About 4 µs (tLTD_Auto) after the last rx_freqlocked the 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.
- Signal detect is available in PCIe and Basic modes. You can monitor rx_signaldetect signal as a loss or presence of a link indicator. rx_signaldetect will assert if there is valid data present at the RX buffer.
- You can implement a PPM detector in the 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.
- Data corruption or RX phase comp fifo overflow/underflow condition in user logic may indicate valid or invalid data at the RX buffer.