Second opinion on timequest constraints

My summary for TQ:

1) If you're "expanding the window", i.e. allowing multiple clock cycles for data to go through, you'll have paird multicycles with a setup of N and hold of N-1. For example, if it's a 10ns clock and you want to give 40ns for the data to go through:

set_multicycle_path -setup 4

set_multicycle_path -hold 3

2) If you're shifting the window, add a multicycle setup. 99.9% your shifting one cycle, so it's:

set_multicycle -setup 2

(Implied is that the hold multicycle is 0, but you could add it if you wanted to be explicit).

The common case for this is when phase-shifting a clock a little. For example, if you phase-shift your destination clock forward 500ps, or you phase-shift your source clock back 500ps, the setup requirement between those clocks will be 500ps. Most likely you want your setup requirement to be the next clock cycle. Adding the following will do that:

set_multicycle_path -from [get_clocks src_clk] -to [get_clocks dst_clk] -setup 2

Your setup requirement will be one clock period + 500ps, and your hold requirement will be 500ps. (Draw out the waveforms and it makes sense.)

3) You don't have to be an expert. It's really easy to add a multicycle, then immediately run TimeQuest and do a report_timing -setup and report_timing -hold between the two points. Look at the difference between the launch and latch clocks. That's all your affecting. Look at them in the waveform viewer too. If it looks like how your design behaves, great. If it doesn't, change the multicycle values you entered and run again. The process might take a few minutes, but it's pretty easy.

Ryan