Overconstraining the Design - 2024.1 English

UltraFast Design Methodology Guide for FPGAs and SoCs (UG949)
Document ID
UG949
Release Date
2024-06-26
Version
2024.1 English

When the design fails timing by a small amount after route, it is usually due to a small timing margin after placement. It is possible to increase the timing budget for the router by tightening the timing requirements during placement and physical optimization. To accomplish this, AMD recommends using the set_clock_uncertainty constraint for the following reasons:

  • It does not modify the clock relationships (clock waveforms remain unchanged).
  • It is additive to the tool-computed clock uncertainty (jitter, phase error).
  • It is specific to the clock domain or clock crossing specified by the -from and -to options.
  • It can easily be reset by applying a null value to override the previous clock uncertainty constraint.

In any case, AMD recommends that you:

  • Overconstrain only the clocks or clock crossing that cannot meet setup timing.
  • Use the -setup option to tighten the setup requirement only.
    Note: If you do not specify this option, both setup and hold requirements are tightened.
  • Reset the extra uncertainty before running the router step.

Overconstraining Example

A design misses timing by -0.2 ns on paths with the clk1 clock domain and on paths from clk2 to clk3 by -0.3 ns before and after route.

  1. Load netlist design and apply the normal constraints.
  2. Apply the additional clock uncertainty to overconstrain certain clocks.
    1. The value should be at least the amount of violation.
    2. The constraint should be applied only to setup paths. 
      set_clock_uncertainty -from clk0 -to clk1 0.3 -setup
set_clock_uncertainty -from clk2 -to clk3 0.4 -setup
  3. Run the flow up to the router step. It is best if the pre-route timing is met.
  4. Remove the extra uncertainty. 
    set_clock_uncertainty -from clk0 -to clk1 0 -setup
set_clock_uncertainty -from clk2 -to clk3 0 -setup
  5. Run the router.

After running the router, you can review the timing results to evaluate the benefits of overconstraining. If timing was met after placement but still fails by some amount after route, you can increase the amount of uncertainty and try again.

Warning: Do not overconstrain beyond 0.5 ns. Overconstraining the design can result in increased power due to the additional logic replication introduced by the implementation tools as well as increased compile time.
Tip: An alternative to overconstraining the design is to change the relative priority of each path group. By default, each clock and user-defined path group is analyzed independently with the same priority during implementation. You can set a higher priority for any clock-based path group using the group_path -weight 2 -name <ClockName> options. The priority of user-defined path groups cannot be changed.