--- Quote Start ---
One simple thing I do to "verify" timing constraints is to constrain the design in a way that I know WON'T meet timing (for example, set an input or output delay to a value that can't possibly be met). Then constrain the design in a way that can easily be met. In each case TimeQuest should indicate a pass or fail condition. If it doesn't, you know something is amiss. This won't catch everything, of course, but I've uncovered a number of errors this way, including errors in my own thinking about how a particular timing constraint works.
--- Quote End ---
I am not sure I understand what your method means. The idea of i/o timing constraints or any internal constraints is that they must be correct first for your design then see if the design passes timing. correct constraints entry is designer's responsibility and the tool can not know that. If you imply that you just enter some random i/o constraints until timing passes then that defeats the purpose completely and it could be either a false pass (or false failure).
Thus timing closure is only as much correct as your entry is.
Honored Contributor
