Forum Discussion
Hi,
The compensation factor is dependent upon the routing that takes place during fitter. With design changed, the placement of the CLKCTRL blocks and the registers also changes. So, it is very much possible to have that variation in the compensation factor.
I agree, PLL does not compensate for the upstream CLKCTRL. It just takes care of the clocks that are generated from it.
Coming back to the original query, want to mention couple of points here.
1) GCLK networks provide less skew for a clock that passes through it.
2) Two different clocks on two different CLKCTRL blocks cannot have identical delays, just because of the fact that they are independent and have to reach to different flops in the chip and different locations.
3) For the PLL generated clocks as well, the same logic applies. They cannot have zero skew between themselves because they drive different paths.
4) The PLL definitely maintain the phase relationship between its input and output clock.
5) As long as the tool reports that there are no timing failures in the design, skews between the clocks should not be a matter of concern.
6) When the data path changes from one clock to other clock, it is better to either provide a set_max_skew constraint or declare that path as a false path.
If you look at a path in the tool driven by the same clock going through CLKCTRL, you will find a near to zero skew, but the same cannot be expected from different clock paths even though they have fixed relation. The skew on all the reported paths between the two clocks however, should remain same. If the tool reports the same clock skew number in these paths, then we are good.
Hope this helps.
Regards.