One of the most common situations that the Timing Analysis clock skew calculations have issues with occurs when a DCM and a non-DCM clock drive the BUFGMUX. The clock skew analysis will find the fastest and slowest paths to the two flip-flops that are driven by the BUFGMUX. The clock skew equation for a data path between FFA and FFB is "clock to FFB(destination)" minus the "clock to FFA(source)". During the setup portion of the analysis, the clock skew equation changes to "clock to FFB(relative-min)" minus the "clock to FFA(max)", and during the hold portion of the analysis, the clock skew equation changes to "clock to FFB(max)" minus the "clock to FFA(relative-min)". The timing tools trace through the clock tree to determine which clock path can be used to give us the most pessimistic clock skew value for the setup and hold analysis. When the timing tools are tracing through the clock paths, it finds the DCM clock path, the fastest to the destination FF and the non-DCM clock path, the slowest to the source FF. This gives us the most pessimistic clock skew. Since the BUFGMUX cannot operate in this manner, the user has to inform the timing tools which of the clock sources of the BUFGMUX to use for clock skew analysis. This is done my placing a PIN TIG on the non-DCM clock pin of the BUFGMUX. The PIN TIG constraint should be related to the less critical clock or least used clock.
In general, this problem occurs when two paths from the same clock pad drive a BUFGMUX with one clock path passing through the DCM and the other is a non-DCM path. The work-around to get the correct skew calculations is to apply a TIG constraint to the output clock of the DCM that goes through the BUFGMUX.
NET "output_clk" TIG;
PIN mybugmuz.I0 TIG #PIN TIG on the less critical clock that drives the BUFGMUX.
This problem has been fixed in the latest 10.1 Service Pack available at:
The first service pack containing the fix is 10.1 Service Pack 3.