Second opinion on timequest constraints

On SlowClock's comment, a multicycle of 2 in TimeQuest does not double the window in which you can pass data(i.e. a clock enabled transfer). A setup multicycle of 2 shifts the window you're targeting. For example, if you have a 10ns clock feeding the source and destination registers, the default setup requirement is 10ns and the hold requirement is 0ns. A multicycle -setup 2 will make the setup requirement 20ns, but will also shift the default hold requirement to be a positive 10ns. So it's still a 10ns window you're transfering data through, just on the next edge. If you want to make the window grow, you would have to add a multicycle -hold 1 to the same path, and thereby the hold requirement would stay at 0ns.

In the Classic Timing Analyzer, this was not the case, where a setup multicycle of 2 would make the setup requirement 20ns but the hold requirement would stay at 0ns. The reason for this is a global setting under Timing Analysis -> More Settings that tells the Classic Timing Analyzer to secretly add a hold multicycle whenever a setup multicycle is added. So the coment is true for Classic, but not TimeQuest. (I've posted a presentation on TimeQuest multicycles to this forum, that might help clear up what's going on...).

As for advice, first thing is that clocking on the falling edge(before the multicycle) hurts your setup requirement, but helps your hold. But your data will be coming from a memory block to the output register, which means you'll have a long setup time. If at all possible, I recommend registering your data on the way out. That alone should get it to meet timing. I would also change the behavior of the DAC to latch on the rising edge. You're going to easily meet the hold requirement just because you have positive delays to get the data out of the FPGA, and it's the setup requirement that could be difficult.