New Contributor
New ContributorHi,
"Is there any reason why the transmitted clock should be modified depending on data content in the sender?"
We are working with the IC vendor to understand that.
"What is the primary problem, do you experience data corruption?"
As i mentioned, we do not see any data corruption in practice. The issue is that the jitter on this clock does not meet the IO PLL cycle to cycle jitter requirements and we would like to understand if we might have some robustness issue here.
unfortunately, such a major design change like using CDR is not an option right now.
Regular ContributorHello,
The Cyclone 10 GX LVDS SERDES expects a stable, continuously running reference clock into the I/O PLL. If the clock’s cycle‑to‑cycle jitter exceeds the I/O PLL requirement in the device datasheet, Altera does not guarantee correct or robust operation even if your current lab tests show no bit errors.
Regards,
Aqid
New ContributorThanks Aqid. This is the is not the answer i wanted but this is the answer i expected :-).
Regarding the cycle to cycle requirement for IO PLL input jitter (tINCCJ), the requirement for Rref > 100MHz is 0.15 UI (p-p). Does p-p mean the difference between the maximal delta between two adjacent cycles and the minimal delta between two adjacent cycles? is the below calculation correct?
measure dTn = Tn - Tn-1 for 1000 cycles.
tINCCJ (p-p) = max(dTn) - min (dTn)
Regular ContributorHi,
Your calculation appears to be correct, at least from my understanding.
From the I/O PLL spec, tINCCJ means the cycle‑to‑cycle jitter tolerance on the PLL clock input.
It specifies the maximum allowable variation between the durations of consecutive reference‑clock periods that the IOPLL can tolerate.
