Common reasons for using the min or max delay constraints are as follows:
- Overconstraining a few paths of the design by tightening the
setup/recovery path requirement.
This is useful for forcing the logic optimization or placement tools to work harder on some critical path cells. This can provide more flexibility to the router to meet timing later on after removing the max delay constraint.
- Replacing a multicycle constraint.
This method is valid but not recommended. It relaxes the setup requirement on a path. The path has active launch and capture edges every N clock cycles. The only option is to overconstrain a multicycle path by a fraction of a clock period. This helps with timing closure during the routing step.
For example, a path has a multicycle constraint of 3. It appears to be the worst violating path after route. It fails timing by a few hundred ps.
During optimization and placement, replace the original multicycle path constraint with the following constraint. Here, 14.5 corresponds to three clock periods (of 5 ns each), minus 500 ps for the required extra margin:set_max_delay -from [get_pins <startpointCell>/C] \ -to [get_pins <endpointCell>/D] 14.5 - Constraining the maximum datapath delay on asynchronous CDC paths
Defining Clock Groups and CDC Constraints describes this technique.
It is not common or recommended to force extra delay insertion on a path
by using the set_min_delay constraint. The default min
delay requirement for hold or removal is usually sufficient to ensure proper hardware
functionality when the slack is positive.