Second opinion on timequest constraints

Thank you again for the replies.

After reading the post by Kaz I tried to meet timing without using the multicycle. I was unable to meet timing by about 1.5ns. I wanted to use a PLL to put a couple of ns negaitve shift on the clock coming in, but unfortunately due to an oversight, this clock is not on a dedicated clock line.

I resorted to the multicycle approach as before and am now registering the data beforehand as recomended by Rysc. I am happy enough with the results except one thing is still confusing me. I don´t have any problems meeting the setup time comfortably, but when it comes to the hold time I am having a little trouble understanding how timequest is doing its calculations.

In my sdc file I have the following constraints in place:

create_clock -name {DAC_PLLLOCK} -period 6.666 -waveform { 0.000 3.333 } [get_ports {DAC_PLLLOCK}]

create_clock -name {PLLLOCK_Virtual} -period 6.666 -waveform { 3.333 6.666 }

set_output_delay -clock { PLLLOCK_Virtual } -max 0.5 [get_ports {DAC_D*}]

set_output_delay -clock { PLLLOCK_Virtual } -min 1.5 [get_ports {DAC_D*}]

set_multicycle_path -to [get_clocks {PLLLOCK_Virtual}] -setup -end 2

So my default hold time should be 3.33ns but taking into account the 1.5ns th requierment in the datasheet, it will be 4.83ns by my understanding. (Writing data out on rising adge and sampling on the falling + th)

Timequest however, when I analyze the data required path, subtracts the 1.5ns from the 3.3ns thus giving a requirment of 1.833ns.

I am sure timequest is correct but I cannot understand why it subtracts the hold time rather than add it.

I meet the hold requirment comfortably on the slow model, but on the fast model, even though timequest tells me I meet it, I don´t think I do. I have attached a snapshot of the worst case hold slack for the fast model. Timequest tells me that it meets timing but I don´t think it should. Notice how on the required path calculation it subtracts the 1.5ns. I would be grateful if someone could explain this to me.

Thanks again for the help.