Second opinion on timequest constraints

You've got a 10ns and 13.333ns period clock. TimeQuest will try to go with the tightest constraint of 3.333ns. Personally I think that is good, and would limit all transfers to be register to register, so that it can easily meet timing. This nicely transfers the whole bus with everything arriving on the same edge. The problem, and this occurs with any solution, is you can't transfer data at the full clock rate, since it's either too fast or too slow than the other clock rate.

If you add a multicycle, you're now potentially passing through multiple edges. You need to know if/when this occurs, and handle it properly. It can get complex quickly. It's definitely do-able, but you need to really plan it out correctly and account for all possible transfers. (And it's hard to say how it will work up front without knowing the data rates, which way you're talking, etc.) But the fact that the clocks are "semi-synchronous" can defeinitely be used to your advantage.