We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 13752

ISE Timing & Constraints - How to constrain clock domain crossing paths?


There are clock domain crossing (CDC) paths in the Unconstrained paths sections in the timing report.
How can I constrain these paths?


1. Synchronous clocks

By default CDC paths associated with automatically or manually related synchronous clocks are analyzed under the PERIOD constraint of the destination clock.

Please refer to (UG612) Timing Closure User Guide for more information on automatically and manually related synchronous clocks.
If you find CDC paths between synchronous clock domains in the Unconstrained paths section, please check the following:
  • MMCM/PLL/DCM output clock domains: make sure you have the period constraint defined for the MMCM/PLL/DCM input clock and that the PERIOD constraint is correctly propagated to the MMCM/PLL/DCM output clocks.
    Also see (Xilinx Answer 37782) for a common issue of auto-propagation failure.
  • Other synchronous clock domains, typically related clocks entering the FPGA device on separate pins: make sure that you specify the frequency and phase relationship of the clocks in their PERIOD constraints.
The following is an example of two manually related clocks
NET "clk133" TNM_NET = "clk133_grp"; 
TIMESPEC "TS_clk133" = PERIOD "clk133_grp" 7.5 ns HIGH 50 %; 
NET "clk33_3p75" TNM_NET = "clk33_3p75_grp"; 
TIMESPEC "TS_clk33_3p75" = PERIOD "clk33_3p75_grp" "TS_clk133" * 4.0 PHASE + 3.75 ns HIGH 50 %; 
Notice that the clk33_3p75 clock requirement is not specified in terms of a number, but instead is related to clk133 by the constraint label TS_clk133 along with a 4.0x larger period, and a phase shift of 3.75 ns.

The default analysis of CDC paths between related synchronous clocks calculates the path requirement by finding the time difference between the closest edges of the two clocks.
Sometimes the default path requirement is unrealistically tight so a FROM-TO constraint needs to be added to adjust the requirement (multi-cycle or max delay) or make it a false path. 

See the following examples:
# Multi-cycle or max delay
TIMESPEC "TS_exception1" = FROM "src_group1" TO "desti_group1"  TS_clk1/2;
TIMESPEC "TS_exception2" = FROM "src_group2" TO "desti_group2"  6.4 ns;
# False path
TIMESPEC "TS_exception3" = FROM "src_group3" TO "desti_group3" TIG;

  2. Asynchronous clocks

By default CDC paths between asynchronous (unrelated) clocks are not analyzed unless timing exception constraints (FROM-TO) are added for those paths.

You can constrain asynchronous CDC paths as a max delay datapathonly or a false path.

You can also apply a FROM-TO constraint between the clock groups: 

See the following examples:
# Max delay datapathonly
TIMESPEC "TS_exception4" = FROM "src_group4" TO "desti_group4"  5 ns DATAPATHONLY;
# False path
TIMESPEC "TS_exception5" = FROM "src_group5" TO "desti_group5" TIG;

Note: Not constraining the asynchronous CDC paths is equivalent to adding a TIG constraint on the paths.
This is because the asynchronous paths are not analyzed when they are not constrained.

  3. Synchronizer for asynchronous CDC paths.

Data transfer crossing asynchronous clock domains should be carefully analyzed by the designer to determine if the CDC paths should be false paths or controlled by a max delay.

In addition to correctly constraining CDC paths, Synchronizer logic (for example a double register synchronizer or a FIFO) needs to be used on data paths crossing asynchronous clock domains to resolve metastability. 

AR# 13752
Date Created 08/29/2007
Last Updated 03/23/2015
Status Active
Type General Article
  • ISE Design Suite
  • ISE