Without knowing the properties of the clocks in question, it's hard to say, but the relationship column represents the time between the launch edge and the latch edge used for the analysis. The value gets doubled if, say, you add a multicycle setup of 2 since that extends out the timing analysis by a clock cycle in the destination clock domain.
Are these all the same clock domain? Are you using multicycle or other timing exceptions like set_max_delay?
Just set_input_delay and set_output_delay? You have clock constraints as well, I presume. Are you using virtual clocks correctly for your I/O? Are these I/O paths or internal paths?
It would help to just see the .sdc file and details on the failing path(s).
EDIT: just noticed there's very large skew on the paths with the halved clock relationship, which could indicate a gated clock and an incorrect use of device clock resources. Definitely need more detail and info.
information is a scarce here, so it's just wild guessing:
is it possible that paths 13 and 14 are lauched by an FF with inverted clock ? some unwanted logic in the clock path perhaps?
Any logic in the clock path will add some delay to the clocks latency values, even if it is not inverting it.
And if this logic perchance inverts the clock, i would assume that this adds half a clock period in addition.
If it is unneccessary logic, get rid of it.
Else try at least to analyze this logic. Can't you produce a timing report which shows your clock-paths in detail?
Try to see how the tool is implementing this in the fpga's fabric. If it for some reason can't use the specialized clock routing ressources to connect to your FF, you get tons of unnecessary delay.
We did not receive any response to the previous question/reply/answer provided, thus I will put this case to close pending. Please post a response in the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.