Loss of lock in the PLL of ALTLVDS_Rx

Yes,

SATA cable consists of two diff pairs. And I use one of them to transmit data and the second pair to transmit clock.

One SATA cable is assigned to transmit from board "A" to board "B". The second SATA cable is assigned to transmit from board "B" to board "A".

Termination is correct, 100 Ohm SMT resistors (for data and clock pairs respectively) at the receiver.

Data rate is 160 Mbps.

Unfortunately, I have no special oscilloscope to view waveform at the receiver. Before production of PCB simulation was made to set impedance of pathes to 50 Ohm.

Also, Quartus II posts message after compilation:

Critical Warning: PLL"altlvds_tx0:inst23|altlvds_tx:altlvds_tx_component|lvds_tx_9hi1:auto_generated|lvds_tx_pll" input clock inclk[0] is not fully compensated because it is fed by a remote clock pin "Pin_90".

It may be the possible reason of loss of lock in the PLL of receiver. But Pin 90 is dedicated clock input (CLK14) in EP3C16Q240C8 and I connected external clock generator (20 MHz) to pin 90.

What pin of EP3C16Q240C8 I need to connect external clock generator ?

How can I determine a dedicated (not remote) clock input pin for PLL used in ALTLVDS_Tx?

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.

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"

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.

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 ?

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.

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).

--- 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.