The Virtex-II Pro X 2.48832 Gb/s - 10.3125 Gb/s Multi Gigabit Transceivers (MGTs) have an automatic lock-to-data feature that allows the MGT receiver to lock to incoming data and to recover a clock synchronous to the data (RXRECCLK). The clock is passed to the application design, where systems can take advantage of it.
The automatic lock-to-data function is controlled by fixed parameters that cannot be changed based on application requirements. The existing parameters might result in non-optimal performance under certain conditions for certain application environments. The non-optimal performance issues include:
- Potentially large drift in RXRECCLK frequency
- Potential receiver lock-up at data rates close to 10Gb/s
- Limited frequency difference tolerance of certain versions of XC2VPX20, Step0 Silicon ONLY
The first two problems might happen only if there is no incoming data at the receiver input, or if the incoming signal quality is significantly below the minimum requirements. This condition is possible in applications where the signal is switched from one source to another, causing a short interruption in the incoming signal. This condition is also possible when the link-partner is set to power down so that no incoming signal is present at the receiver. The first issue above is a concern only if the system actually uses the RXRECCLK during the problem condition.
This Answer Record provides solutions for the three performance issues either separately or simultaneously. It also describes how to overdrive the receiver's fixed lock control parameters if an application requires a more flexible control over the receiver operation.
The Virtex-II Pro X receivers have three modes of operation controlled by the two-bit PMARXLOCKSEL signal. The receiver can be set to lock-to-data (PMARXLOCKSEL = '10'), lock-to-reference (PMARXLOCKSEL = '01'), or AUTO-mode (PMARXLOCKSEL = '00'). The AUTO-mode operates so that the receiver is internally set to lock-to-reference when the incoming data rate significantly deviates from the selected data rate. If the receiver detects incoming data, and the incoming data rate is within the predefined limits, the receiver locks to the data instead of the reference.
The Virtex-II Pro X MGTs have fixed parameters to control the receiver operation. Under certain conditions, the parameters are not optimal, resulting in unexpected changes in the recovered clock (RXRECCLK) characteristics and the receiver operation. Typically, the changes can be observed if there is no incoming data, or if the incoming data has discontinuity, which can happen if the data is switched from one source to another. Under the no-data condition, the RXRECCLK frequency might drift significantly from its nominal frequency. In an extreme case, a nominal of 155.52 MHz RXRECCLK at 2.488Gb/s data rate might periodically drift up to 300 MHz. If the application uses the RXRECCLK clock under this condition, the timing of the application design can fail unless significant margins in the timing constraints are used.
Another unexpected behavior might be observed at data rates around 10 Gb/s. Under the no-data condition, the receiver might lock up so that a PMA reset is required to re-establish correct operation.
The third limitation is incorrect operation when the incoming data is not synchronous to the BREFCLK for certain versions of XC2VPX20 FPGAs. The versions that experience the problem are shipped with an errata describing the problem and recommending an external solution. This core provides the recommended external solution.
This Answer Record presents a way to overdrive the MGT's internal lock control function either to improve the operation under the problematic conditions, or to provide an application with more flexible control over the receiver operation.
When to Use the Module
You should consider using the core if your system has one of the following conditions:
Operation at around 10Gb/s
- Core might be needed to handle the potential lock-up problem.
- If lock-up is the only concern, the mgtlockup_det module might be enough.
Operation at any rate, if the design needs continuous RXRECCLK, and the MGT that is providing the RXRECCLK has discontinuities in the incoming data
- If the system tolerates large frequency variation of the RXRECCLK, when there is no data at the receiver, core is not needed.
If a version of XC2VPX20, with errata recommending an external solution for the limited tolerance in asynchronous mode is used
- This core provides the recommended solution for the errata item.
What to Expect from the Module
The core does not completely fix the issues, but it improves the characteristics. You should expect the following improvements when using the core:
Operation at around 10Gb/s
- Core automatically detects the lock-up condition, and clears it.
- However, if lock-up was detected, an interruption in the RXRECCLK has occurred; so if the system was using the RXRECCLK, a reset might need to be issued after the RXRECCLK re-appears, and the LockUpDetected signal goes Low.
Tighter RXRECCLK frequency control
- The maximum drift is limited to about +/-20 MHz around the nominal frequency under any conditions; the system should account for this wide variation (even when using the core).
Correct operation under asynchronous conditions for all XC2VPX20 versions
- With the default parameters, a minimum of +/-1000 ppm frequency difference tolerance between the incoming data and the internal reference is expected under all conditions.
- The tolerance can be varied by changing the parameters, should the application have different requirements.
The design uses FPGA fabrics logic to implement the Frequency Difference Detector (FDD) and other controls for the MGT receiver operation to address the previously mentioned limitations. The parameters for the FDD can be changed to better fit the application requirements. The design also includes a feature to automatically detect and clear the lock-up condition, which is possible for applications operating at data rates around 10 Gb/s. However, it cannot prevent the lock-up, and further actions from the application side might be needed to properly handle the lock-up condition.
The block diagram of the reference design is shown in Figure A. Table A shows the I/O description of the module. The top-level of the design is mgt_lockctrl module, and it uses two sub-modules, a frequency difference detector, mgt_fdd, and a lockup detector, mgtlockup_det.
The mgt_fdd module has two clock signal inputs and an output signal indicating whether the clock frequencies of the two clocks are within the programmable threshold. This information is used by the top-level module to externally force the receiver to either lock-to-data or lock-to-reference mode by controlling the MGT's PMARXLOCKSEL signal. The mgt_fdd module also has an Enable and a Xreset inputs, as well as two status outputs, FddCycleRdy and FddCntEna. The instantiation of the main mgt_fdd module is called FDD_COARSE. A second instantiation of the same module, FDD_FINE, is used to provide tighter control of the RXRECCLK frequency as described below.
For correct operation in the lock-to-data mode, the frequency difference of the incoming data and the receiver PLL should not exceed 4000 ppm. Consequently, a relatively long counter is needed to determine when to switch to the lock-to-data mode. On the other hand, if this long counter is used to determine when to switch from lock-to-data back to lock-to-reference, a significant delay is generated, which might allow the receiver PLL (and the RXRECCLK) to drift, if no data is present at the input. To shorten this delay, the mgt_lockctrl uses second instantiation of the mgt_fdd module, FDD_FINE, with different parameters. The threshold of the frequency difference for the second mgt_fdd module is wider resulting in faster operation, and consequently, the second mgt_fdd is used only to switch from lock-to-data to lock-to-reference.
The module mgtlockup_det is used to detect a permanent lockup, which is possible at data rates close to 10Gb/s. The module detects if RXRECCLK is not present, and forces a receiver PLL reset condition (PMARXLOCKSEL='11') until the clock re-appears. The module cannot prevent the lockup condition, but it can be used to automatically detect and clear the condition.
Table B describes the parameters for the mgt_fdd module. When enabled, the mgt_fdd module operates so that one counter is used to count a fixed number of cycles on BrefClk set by parameter BREFCLK_FULLCNT_VALUE. At the same time, the RxRecClk counter is counting cycles on the recovered clock. When the BrefClk counter reaches BREFCLK_FULL_CNT_VALUE, a comparison on the RxRecClk count value is made against the THRESHOLD_LOW and THRESHOLD_HIGH values. If the RxRecClk counter value is between the thresholds, FineLoopEna is set to HIGH; otherwise, it is set to LOW. By changing the BREFCLK_FULL_CNT_VALUE and the THRESHOLD_LOW and THRESHOLD_HIGH values, the frequency difference tolerance and the loop operation of the receiver can be altered. The BREFCNTRWIDTH can be used to set the number of bits in the counters to match what is required by BREFCLK_FULLCNT_VALUE. In this way, the counters can be kept as small as possible.
Each MGT requiring control needs its own instantiation of the mgt_lockctrl module. The clock inputs must be directly connected to the MGT clock outputs: BrefClk must be connected to TXOUTCLK, and RxRecClk must be connected to RXRECCLK. Global clock routing cannot be used, especially if several MGTs need to be controlled. Since global clocks cannot be used, further constraining of the logic placement is needed for the Place and Route to successfully meet the timing requirements. Table C shows an example User Constraints File to control the placement of the core logic close to the MGT. These constraints have been tested for several different data rates and designs, but they do not automatically guarantee that timing will be met. You should carefully analyze and verify the timing report of each design to ensure that no setup or hold violations exist.
The reference design is located at:
This Xilinx Answer provides you with an example of how to overdrive the receiver internal lock control to improve performance characteristics under certain application conditions.
For more information on RocketIO X Transceivers, see the RocketIO X Transceiver User Guide at: