AR# 50638


14.1 TIMING_ANALYZER - Is there a problem with the propagation of Discrete Jitter from DCM/PLL through a BUFGMUX?


I have seen that the Discrete Jitter in my clock path seems to be higher than expected. After analyzing the path, I found a BUFGMUX which it has connected a slower clock signal from a DCM/PLL.

If the tools analyze only the worse case (fastest clock path, blue path), why do I have the Discrete Jitter from the secondary clock path in the Timing Analysis, even though this PLL/DCM is not in the reported path?



Timing report info:

This is a known issue in the Timing Analyzer tool.

From the Timing Analysis, it is possible to see the Discrete Jitter in the clock path for the FF affected ("toggle2"). A normal value for the Discrete Jitter from a DCM/PLL should be half of the reported value. ~ 0.224 ns. This can be checked in the "Data Sheet: DC and Switching Characteristics".

The only Discrete Jitter for the FF should come from "ck_100_200i/pll_base" component. However, the tools add the Discrete Jitter coming from the Secondary PLL "ck_25_100+125_feci/pll_base", even when the PERIOD constraint for "pl_fpga_ck" has set up a higher priority.

To work around the error, the Timing report can be fixed by TIG, the secondary input clock to the BUFGMUX. After that, the only Discrete Jitter is the one associated to the PLL in the wanted clock path.

AR# 50638
Date 01/16/2013
Status Active
Type Known Issues
People Also Viewed