Identifying Tight Timing Requirements - 2022.1 English

UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs (UG949)

Document ID
UG949
Release Date
2022-06-08
Version
2022.1 English

For each clock pair, the clock interaction report also shows setup requirement of the worst path. Sort the columns by Path Req (WNS) to view a list of the tightest requirements in the design. Review these requirements to ensure that no invalid tight requirements exist.

The Vivado tools identify the path requirements by expanding each clock out to 1000 cycles, then determining where the closest, non-coincident edge alignment occurs. When 1000 cycles are not sufficient to determine the tightest requirement, the report shows Not Expanded, in which case you must treat the two clocks as asynchronous.

For example, consider a timing path that crosses from a 250 MHz clock to a 200 MHz clock:

  • The positive edges of the 200 MHz clock are {0, 5, 10, 15, 20…}.
  • The positive edges of the 250 MHz clock are {0, 4, 8, 12, 16, 20}.

The tightest requirement for this pair of clocks occurs when the following is true:

  • The 250 MHz clock has a rising edge at 4 ns.
  • The next rising edge of the 200 MHz clock is at 5 ns.

This results in all paths timed from the 250 MHz clock domain into the 200 MHz clock domain being timed at 1 ns.

Note: The simultaneous edge at 20 ns is not the tightest requirement in this example, because the capture edge cannot be the same as the launch edge.

Because this is a fairly tight timing requirement, you must take additional steps. Depending on the design, one of the following constraints might be the correct way to handle these crossings:

  • set_clock_groups / set_false_path / set_max_delay -datapath_only

    Use one of these constraints when treating the clock pair as asynchronous. Use the report_cdc Tcl command to validate that the clock domain crossing circuitry is safe.

  • set_multicycle_path

    Use this constraint when relaxing the timing requirement, assuming proper clock circuitry controls the launch and capture clock edges accordingly.

If nothing is done, the design might exhibit timing violations that cross these two domains. In addition, all of the best optimization, placement and routing might be dedicated to these paths instead of given to the real critical paths in the design. It is important to identify these types of paths before any timing-driven implementation step.

Figure 1. Clock Domain Crossing from 250 MHz to 200 MHz