FPGA vendor often allow for practices that aren’t recommended, simply because there are users out there that employ them.

Specifically, I have a follow-up post to this one, which shows a not-too-exotic case which required set_max_delay assignments:

http://billauer.co.il/blog/2018/08/quartus-sdc-constraining-pins-derived-clock/

I have seen several instances of expert users showing how set_max_delay can fix setup timing problems. Also I see expert advice cautioning against using set_max_delay.

One Altera note includes “For cases where you want to use set_max_delay and set_min_delay to establish
an I/O timing requirement (tSU, tH, tCO, and tCO-min), you must constrain the port using set_input_delay/output_delay with a virtual clock. The delay value can be 0 for -max/min in set_output_delay/set_input_delay because
set_max_delay/set_min_delay is used to override the setup and hold requirement and thereby establishing the tSU, tH, tCO, and tCO-min requirement. Because you set your requirement in set_max/min_delay, you do not need to specify a value for the set_input_delay or set_output_delay constraint, but you still must use a virtual clock to make the clock transfer be correctly identified as an I/O transfer. In this way, derive_clock_uncertainty applies uncertainty correctly on this path.”

Question – If Quartus has AI to achieve timing closure, why do we sometimes need additional undesirable? set_max_delay constraints on some paths, to achieve closure ? i.e. if a solution is possible, why does Quartus make us add these quote Altera “dangerous” constraints to make it happen ? Thanks, Steve