How does clock skew relate to Hold/Race Checks functionality?
Hold/Race checks are performed on register-to-register paths by taking the data path (Tcko+Troute_total+Tlogic_total) and subtracting the clock skew (Tdest_clk - Tsrc_clk) and the register hold delay (Th). In the TWR report, slack is used to evaluate the hold check: Negative slack indicates a race condition; positive slack means there is no race condition. The following equation is used for hold slack calculations:
Hold Slack = Tdata - Tskew - Th
The detailed path will be reported under the constraint that contains that data path. The path will be listed by the slack with respect to the requirement. There will be a (-Th) identifier of the hold path delay type. This (-Th) would appear after the hold delay type to help identify race conditions.
Hold Check Issues
Hold checks are performed on all global and local clock resources; the data path is not adjusted to show possible variances in the PVT across the silicon. You will not generally see race violations, as you need a very short data path and a large clock skew to get this problem.
The hold slack does not relate to the constraint requirement; this may be confusing when you look at the slack and the minimum delay/period for the constraint. Only the slack from setup paths affects the minimum delay/period for the constraint.
It is possible to account for clock skew regardless of the resources used for the clocks, but this can lead to problematic PAR behavior. The current protocol between PAR and the timing engine does support a means to minimize skew, and it can maximize a clock delay for a specified data path. This means that PAR can change the routing to fix a hold violation.
For PERIOD constraints, the skew-checking works as outlined above.
If the constraint is a FROM/TO, it is assumed that the user has accounted for (within the value of the constraint) any known external skew between the clock sources if the endpoint registers do not share a common clock. If the registers share any single common clock source, the skew is calculated only for the common clock sources.
If no common clock source points are found, the skew is the difference between the maximum and minimum clock paths.
TWR reports hold paths only if a race violation has occurred. The clock skew is reported in the path header, but the delays to the source clock pin and destination clock pin are not included.
You can determine these delays by going into Timing Analyzer and using "Analyze Against User Specified Paths ... by defining Endpoints...". Specify the clock pad input as the source. The clock delay from the pad to each register clock pin will be reported. (This will also work for DLL/DCMs paths.)
To obtain the clock skew, subtract the destination clock delay from the source clock delay. Paths under a constraint are always sorted by slack. Race violations are designated as negative slack and are sorted with the setup violations also represented in slack:
(Tsu slack = constraint_requirement - Tclock_skew - Tdata_path - Tsu)
The delay value for the hold of the register is presented in the detailed section of the path. To obtain the slack value at the beginning of the path, take the clock skew and subtract the total delay from the detailed portion.