Forum Discussion
Hi User Von SCS
Sorry for late response due to long holiday here.
May I know if you are currently using the ALTLVDS with DPA or non-DPA mode?
By referring to doc below:
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altlvds.pdf
Section 1.5.3.1 explaining the DPA operation each time the DPA shifts the phase taps during normal operation to track variations between the relationship of the reference clock source and the data. Depending on different FPGA family, the reset mechanism would be different.
Let me know if this help in your issue.
Thanks.
Eng Wei
Hi Eng Wei
thanks for your reply.
We are using ALTLVDS_RX in non-DPA mode.
Thanks
- EngWei_O_Intel5 years ago
Frequent Contributor
Hi User Von SCS
Are you able to try out DPA mode to overcome your design issue?
Thanks.
Eng Wei
- UVonS5 years ago
New Contributor
Hi Eng Wei
I only have limited understanding of the ALTLVDS_RX DPA mode.
We are seeing spurious clock jitter at the ALTLVDS_RX clock input which in turn seems to cause wrong acquisiton of the data (ALTLVDS_RX PLL lock remains). So "usually" transmission is working fine, and only sometimes this clock jitter occurs in the transmitting device for a short time causing CRC errors. Ideally we want to avoid CRC completely in this case.
Can DPA mode be used to solve this kind of problem?
- EngWei_O_Intel5 years ago
Frequent Contributor
Hi User Von SCS
It really depends on how the jitters look like. If it is a phase shift, it will work. If the clock is heavily distorted, then problem might still exist.
Using external PLL allowing us to control parameters like bandwidth setting, it might or might not help depends on the jitters behaviour.
The best solution is still fixing the source that is causing the jitters, as a clean source is important to feed FPGA.
Meanwhile, I will be off for a week from now. Allow me some time to get back to you if you have further question.
Thanks.
Eng Wei