Honored Contributor
Honored ContributorI don't consider item 2) very risky. If the user is only looking at the Fmax Summary and ignoring the Setup Summary in red right next to it, that's user error. If they're only looking at the text reports and skipping setup summary(which might be easier to do), that's still user error.
You don't have to shift the clock and have the option to just modify delay values, but when the external clock is truly shifted, it's more accurate to shift the clock in your constraints then to try to figure out how to modify the delays. It can be done either way, but it provides an option. For the case of input data clocked by clock from FPGA, using the clock coming out of the FPGA is absolutely necessary. The FPGA sends a clock out, and the delay to get out of the FPGA can vary compile to compile. This delay is then used as part of the calculation for the data coming back. If you couldn't do this, you'd have to modify the constraints after every compile to account for what happened during the fit. (Most likely the delay isn't changing, but I have seen users send out clocks that are on local routing, in which case it does vary a decent amount and this methodology is required.)
