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, which can provide more flexibility to the router to meet timing later on (after removing the max delay constraint).
- Replacing a multicycle constraint.
This is a valid but not recommended way to relax the setup requirement on a path that has active launch and capture edges every N clock cycles. Although it is the only option to overconstrain a multicycle path by a fraction of a clock period to help with timing closure during the routing step. For example, a path with a multicycle constraint of 3 appears to be the worst violating path after route and fails timing by a few hundred ps.
The original multicycle path constraint can be replaced by the following constraint during optimization and placement, where 14.5 corresponds to 3 clock periods (of 5 ns each), minus 500 ps that correspond to amount of extra margin desired:set_max_delay -from [get_pins <startpointCell>/C] \ -to [get_pins <endpointCell>/D] 14.5
- Constraining the maximum datapath delay on asynchronous CDC paths
This technique is described in Defining Clock Groups and CDC Constraints.
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.