virtual clock source latency

For source-synchronous, it's not that the clock delay doesn't matter, it's that it tends to "cancel out" with the data delay(this is when the FPGA is sending source synchronously). I was wondering if that was what you meant when you said it doesn't matter. Otherwise I'm not sure how it doesn't matter. If the clock delay is 5ns on one compile and 150ns on the next compile, I assume that's going to affect timing. Obviously that's never going to happen, but shouldn't the clock path be part of the analysis?

Usually multicycles are the correct solution. For example, if you have a 20ns clock period and are sending data out, but the clock delay is 15ns, the data delay is 4ns and the setup requirement of the external device is 5ns, then you miss timing by 4ns. If 20ns really were the requirement, then I think the clock delay is very important. If you've got multiple cycles to get there and so the 15ns delay doesn't matter too much, then multicycles would apply. (If I'm missing something in what you're doing, please elaborate...)