01-21-2020 03:43 AM
I had generated one MMCM using VIVADO, with i/p clock as 135M and o/p clocks are as 270M, 135M and 25M, the phase degree of 135M(i/p) and 270M(o/p) is zero.
After sometime the i/p clock stops, which results in "lock" going low after one PFD clock cycle, so i deasset the reset of the MMCM, and once clock restarts again, the reset is asserted almost around 6 clock cycle later w.r.t i/p clock of the MMCM in order to get the lock again and to ensure that their is no phase violations. However lock is coming after some delay, but the phase relation between 135M(i/p) and 270M(o/p) is violating.
Why this phase violation happening??
01-21-2020 06:00 AM
01-21-2020 10:17 PM
I am using VCU118 board.
Actually i had designed one logic in which once the clock stops and lock goes low, the reset is desasserted, so during the time when their is no clock i/p the MMCM is in reset, and once the clock start again the counter present in the logic count for 6 clock cycles and after that the reset is asserted.
So should i keep mmcm in reset for some more time??
But once all the above steps are completed the lock comes, the clocks are phase aligned, and actual phase violation happens after 50us, why is it so?? The i/p clock is continuous now and their no change in the phase/frequency of the clock.
01-22-2020 01:43 AM - edited 01-22-2020 01:44 AM
What is the status of CLKINSTOPPED and CLKFBSTOPPED outputs when the phase error occurs?
01-22-2020 06:34 AM - edited 01-22-2020 09:17 AM
....but the phase relation between 135M(i/p) and 270M(o/p) is violating.
How much phase error/violation are you seeing? -and how are you routing the clocks out of the FPGA so that you can measure the phase error/violation?
Please note that MMCM outputs have error/resolution for phase settings as described on page 74 of UG472(v1.14) for 7-Series devices and on page 41 of UG572(v1.9) for UltraScale devices.
You can avoid some of the phase error associated with MMCM outputs by using BUFGCE_DIVs in parallel as described on page 119 of UG949(v2019.2).
02-02-2020 11:53 PM
Sorry for the late reply, as i was engaged in some other work. Actually i am seeing that, my i/p clock is not exactly 135M throughout, as it is coming from another phy module.
So when i generated the MMCM i gave i/p clock as 135M, but from phy it is coming 135.030, and after some time it suddenly changed to 134.924 for few cycles, and again comes to comes to 135.030.
But lock reamins 1.
Accordingly o/p is changing, but its not instantaneous obviously, i want to know how many cycles does MMCM takes to generate o/p based on its i/p clock, can we reduce to as low as possible??
what is the PPM range, or a predefined window for phase alignment for which lock goes down??it this configurable??
02-03-2020 01:21 AM
02-07-2020 05:33 AM
...i want to know how many cycles does MMCM takes to generate o/p based on its i/p clock, can we reduce to as low as possible??
As drjohnsmith suggests, the maximum locking time for the Virtex UltraScale device on the VCU118 board can be found in device datasheet (DS923 in your case). I find from DS923 that MMCM_TLOCKMAX is 100us.
However, since you say “lock reamins 1” then you are asking about the loop-bandwidth of the MMCM LOCKED circuitry. I am not aware of direct adjustment for this loop-bandwidth. However, I suspect that some settings in the Clocking Wizard (eg. Jitter Optimization) influence loop-bandwidth.
..what is the PPM range, or a predefined window for phase alignment for which lock goes down??it this configurable??
I cannot find specification of when exactly the MMCM looses LOCKED. I suspect it is a complicated specification that involves both magnitude and time-duration of input-clock deviations from a desired value. However, in DS923 we find the MMCM_FINJITTER specification of “ < 20% of clock input period or 1 ns Max” – and from this you might infer something about maximum-tolerated frequency-phase deviations on the input-clock.
Finally, you might try using the PLL to see (experimentally) whether it remains LOCKED for higher deviations of the input-clock than the MMCM.