setup and hold time with set_input_delay

So your clock coming into the FPGA(from the PPC) is:

create_clock -period 15.0 -name ppc_clk [get_ports ppc_clk]

(Naturally the port name will be different, you can give it whatever name you want, and the period might not be correct, as I wasn't sure if it was 6.6666)

The external clock is:

create_clock -period 15.0 -name ppc_ext

So we have an external clock with a period of 15.0ns and the FPGA clock with the same. Now, since you're inverting the clock in the FPGA(and TimeQuest will automatically know that), it will know you have rising edges at 7.5, 22.5, etc. So when the source clock ppc_ext has rising edges at 0, 15, etc., and the destination is inverted, you end up with a setup relationship of 7.5ns and a hold relationship of -7.5ns. If that doesn't make sense, draw the clocks out, and you'll see that when ppc_ext launches data, it's a setup failure if the data delay is greater than 7.5ns, and a hold failure if it's less than -7.5ns.

So everything looks good, and you probably have tons of margin. But you haven't accounted for any differences between your clock and data coming into the FPGA. There are a few ways to do this, but when it's source-synchronous, I like to think of set_input_delay as showing slack. So let's say the worst case scenario is the data leaves the PPC 1ns after the clock, and it has a 500ps longer trace delay(so in essence, it hits the port of the FPGA 1.5ns after the clock hits the port.) That would be:

set_input_delay -clock ppc_ext -max 1.5 [get_ports PPC_DATA*]

Since our setup relationship was 7.5ns, Quartus/TQ knows you will have a setup failure only if the data delay inside the FPGA is 6ns longer than the clock delay. (Remember it's cumulative. The clock relationship gave us 7.5ns to work with, 1.5ns of that was chewed up outside of the FPGA, and there will be a setup failure if the FPGA chew up the final 6ns.)

Does that make sense? Try doing the hold timing and what your thoughts are for that.