Use Cases - 2024.1 English

UltraFast Design Methodology Guide for FPGAs and SoCs (UG949)

Document ID
UG949
Release Date
2024-06-26
Version
2024.1 English

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.