Forum Discussion
Honored ContributorLoss of lock in the PLL of ALTLVDS_Rx
Hi,
I have two similar boards based on Cyclone III. My project works in both boards. This project performs exchange of data between boards with LVDS (physical link is made by SATA cable and connectors). Two boards are connected by two SATA cables. Accidentally (it may be very sparse), I see the loss of lock in the PLL of ALTLVDS_Rx (I capture falling edge of output "rx_locked"). What can be the reason of it ?23 Replies
Altera_ForumI'm sorry, but I don't know how can I get information about bandwidth setting of PLL ALTLVDS_Tx and ALTLVDS_Rx.
PLLs of ALTLVDS_Tx and ALTLVDS_Rx are configured as internal (incorporated into ALTLVDS_Tx/Rx) but not external. Only one PLL (which generates internal clocks for my logic) is accessible to get info about bandwidth. In the section "Bandwidth/SS" of wizard it was configured as "Auto". I set it option to Preset -> "Low" but it didn't help.- Altera_Forum
Did you check the PLL bandwidth setting? I never needed to change anything, also with cascaded PLLs, but the device handbook mentions, that the bandwidth of a cascaded PLL should be set to "high". Unfortunately, it forgets to tell about the absolute bandwidth numbers.
- Altera_Forum
I tried project with disabled option "Use shared PLL(s) for receivers and transmitters" in both ALTLVDS_Rx and ALTLVDS_Tx. But losses of lock in the PLL still exist.
The problem may be concluded in external clock generator. PDF does not contain info about jitter of GXO-7531, and this generator is rather cheap to be an excellent product. - Altera_Forum--- Quote Start --- About clocking scheme. --- Quote End --- Yes, that would be the standard source synchronous scheme in my understanding. That means, if the design is using both a LVDS receiver and transmitter, it would use two sepearate PLLs (respectively the Tx PLL shared with the system clock), because Rx-PLL is clocked from the transmitter and Tx-PLL locally.
- Altera_Forum
Dear FvM,
thank you for your help. Your idea is interesting about "...selected common rx_tx_pll". I didn't emphasize this option in wizard. Now, I have disabled option "Use shared PLL(s) for receivers and transmitters" in both ALTLVDS_Rx and ALTLVDS_Tx. And I'll try modified project tomorrow. About clocking scheme. External clock generator is connected to pin 90 of EP3C16Q240C8. In Quartus II the signal from pin 90 feeds the main PLL which generates internal clocks for my project. Also, the signal from pin 90 is connected directly to input "tx_inclock" of ALTLVDS_Tx. As to ALTLVDS_Rx, its input "rx_inclock" is defined as differential (LVDS) and connected to pins DIFFCLK_xx (p and n) of EP3C16Q240C8. Therefore, PLL of ALTLVDS_Rx receives its clocks from another board (i.e. from output "tx_outclock" of ALTLVDS_Tx of another board). - Altera_Forum
Frequency stability of a crystal oscillator doesn't tell much about it's jitter. Generally, crystal oscillator jitter is very low, except for some programmable oscillators (they may be sold as fixed frequency devices though).
I don't excactly understand your clocking scheme. You are operating the receiver source synchronous, with an external reference clock from the transmitter, why have you selected common rx_tx_pll? I think, the discrepancy with outclock_divide is due to the fact that actual LVDS fast clock frequency is only half the output bit rate, and no bug. - Altera_Forum
I use GXO-7531 (Golledge) as external clock generator. Its features are: frequency = 20 MHz, frequency stability = 100 ppm.
May be 100 ppm is bad with relation to jitter ? - Altera_Forum
Also, there is a very interesting moment in report:
Info: Parameter "outclock_divide_by" = "4" But in Wizard of ALTLVDS I configured "outclock divide factor = 8" !!! It is obvious disagreement which may be the bug of Quartus II. - Altera_Forum
The PLL settings of ALTLVDS_Tx are follows (taken from report of compilation):
Info: Instantiated megafunction "altlvds_tx0:inst23|altlvds_tx:altlvds_tx_component" with the following parameter: Info: Parameter "common_rx_tx_pll" = "ON" Info: Parameter "deserialization_factor" = "8" Info: Parameter "implement_in_les" = "ON" Info: Parameter "inclock_data_alignment" = "UNUSED" Info: Parameter "inclock_period" = "50000" Info: Parameter "inclock_phase_shift" = "0" Info: Parameter "intended_device_family" = "Cyclone III" Info: Parameter "lpm_type" = "altlvds_tx" Info: Parameter "number_of_channels" = "1" Info: Parameter "outclock_alignment" = "UNUSED" Info: Parameter "outclock_divide_by" = "4" Info: Parameter "outclock_duty_cycle" = "50" Info: Parameter "outclock_multiply_by" = "1" Info: Parameter "outclock_phase_shift" = "0" Info: Parameter "output_data_rate" = "160" Info: Parameter "pll_self_reset_on_loss_lock" = "OFF" Info: Parameter "registered_input" = "TX_CORECLK" Info: Parameter "use_external_pll" = "OFF" - Altera_Forum
The warning should be irrelevant in my opinion, because delay skew isn't an issue here and particularly not causing locss of lock.
I'm not sure what's forcing the choice of a TX PLL in your design, most likely a dedicated clock output used for the clock signal transmitted to the receiver. Otherwise Quartus would choose the PLL according to the clock input, if the related PLL isn't already assigned in the design. The clock resource matrix can be seen in the device manual. A PLL clocked by another PLL (as it's the case with the RX PLL) should be set to high bandwidth according to the device manual. I'm not sure if this done by Quartus autmatically, check the PLL settings in the compiler report.
