fix setup hold

However, if you have a bad clock design - say one clock coming through one BUFG, and another coming through two BUFGs, then the skew will be large (several nanseconds), then the tool will likely not be able to fix them. This is not a tool bug, but an error in design - you need to design clocking systems that use the resources of the FPGA properly.

As for the second case - hold time violations on inputs generally need to be fixed using proper interface design. You either need to use an MMCM/DCM to adjust the phase of the capture clock so that the clock is centered in the data eye, or use IDELAY cells to move the data over the clock. Again, it is really up to the user to design the capture mechanism, using the dedicated clock and IOB resources in the FPGA. The OFFSET IN in these cases merely acts as a mechanism to ensure that you have the system designed properly. You should never rely on the tool to fix hold time violations in interfaces by adding buffers/routing delay...

If the Hold Time Violation is associated with an OFFSET IN constraint, the data path is faster than the clock path. Either increase the delay associated with the data path or decrease the delay associated with the clock path.

To decrease the clock path delay, verify that the design is using the global clocking resources. You can also run PAR with a -k option, which tries to perform limited rip up and rerouting to solve problems.

If the Hold Time Violation is associated with a PERIOD constraint, the data path is faster than the clock skew. The resolution is similar to a Hold Time Violation in an OFFSET IN constraint, but decrease the clock skew instead of just the clock path delay.

To decrease the clock path skew, verify that the design is using the global clocking resources. You can also run PAR with a -k option, which tries to perform limited rip up and rerouting to solve problems.