Use Cases - 2021.1 English

Versal ACAP Hardware, IP, and Platform Development Methodology Guide (UG1387)

Document ID
UG1387
Release Date
2021-07-26
Version
2021.1 English

Common reasons for using the min or max delay constraints are as follows:

  • Over-constraining 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 over-constrain 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.