set_max_delay vs set_net_delay

set_max/min_delay includes clock skew, while set_net_delay does not. (I'm also not sure if set_net_delay goes through LUTs or is only for reg to reg paths. I never use set_net_delay).

set_max/min_delay is basically telling TQ what the setup or hold relationship should be. For example, if you have a 10ns clock and you wanted to say a particular path should have 2 cycles, you would normally do a multicycle -setup 2 and multicycle -hold 1, to make the setup relationship 20ns and hold of 0ns. You could also do set_max_delay 20 and get an identical analysis. The benefit of set_max/min_delay is that you can give it any number you want, so if you had two registers after an asynchronous transfer and wanted to overconstrain the path to give time for the metastability to settle, you can directly do a set_max_delay of whatever value you want.

There is also a set_data_delay that is new, and used to constrain just the data path without worrying about clock delays. Technically, this doesn't make sense. For example, let's say your source clock delay was 3ns and your data path was 6ns, so the data arrives at the latch clock at time 9ns. If you ignore clock delays and have a set_data_delay(or set_net_delay) of 6ns, it meets timing. Now let's say the data path moves to 7ns but the clock path is 2ns. The data arrives at the latch register at the exact same time and yet it now fails timing. In reality, most clocks are on global clock trees with fixed delays, so there is an assumption it won't change that is fairly valid, but it's still a bit iffy.