07-06-2018 06:49 AM
Hello, I have three questions that I have broken down into separate sections in this post:
I am aware of the CPLL locking issue described on page 65 of PG182 which states this "In UltraScale+ GTH/GTY transceiver CPLL may not be able to reliably lock in the following circumstances: After configuration, Removing/re-applying reference clock, Asserting/de-asserting CPLLPD". Is there any additional information about the CPLL locking issue? For example, I'd like to know if the CPLL asserts the lock signal too early, if it asserts and de-asserts the lock signal repeatedly, or if it sometimes just does not lock at all.
I have also read about the CPLL Calibration block and that it is automatically used by the transceiver wizard if you are using a CPLL for either TX or RX of a transceiver. Is there any additional documentation describing its functionality other than what is described in PG182? It doesn't get into detail, it mostly just says this "The solution for this issue is to include the CPLL Calibration block".
Lastly, on page 67 of PG182, it says this "USER_GTPOWERGOOD_DELAY_EN user parameter has been added for enabling this. You should not set the value of this parameter to 0 when CPLL is enabled, as the CPLL Calibration block which is mandatory could be using the GT Reference clock source." Could you expand on how the delayed powergood signal impacts the CPLL calibration block- because I don't see a powergood signal being used in the port list of the CPLL calibration block?
07-10-2018 06:17 AM
I believe the CPLL calibration block uses the TX clock sourced from TXOUTCLK via a BUFG_GT.
The powergood signal in turn is then wired to the CE pin of this BUFG_GT. You can confirm this via schematics or looking directly into the RTL.
You could monitor/debug the CPLLOCK signal, i.e. having a sticky bit for lock/unlock conditions and access these via registers.
07-12-2018 01:26 AM
1, besides pg182, here is some more info regarding the CPLL lock issue.
"In the failure state, the CPLL might be stuck at an invalid output frequency and the CPLLLOCK signal might incorrectly be high."
2, You don't have to look into details of the cpll calibration block. You can regard it as one of steps for GT initialization.
do you encounter some issues with cpll?
3, GTPOWERGOOD delay module affected the RESET_IN of CPLL calibration block.
in summary, please tell us what issue do you encounter in your design. we can start from there.