**UPGRADE YOUR BROWSER**

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!

General Description:

I place an odd-numbered value on my PERIOD constraints, and the timing tools transform the PERIOD constraint based upon the output taps of the DCM. These new PERIOD constraint values are off by a picosecond, or report very large minimum periods (ms).

PAR also presents the following table:

Why does this happen? How do I fix this behavior?

Trace/Timing Analyzer attempts to find a relationship between two clocks whose times do not actually differ; however, due to rounding errors, they appear to differ by a picosecond. These minute rounding errors can then cause very large period calculations.

To work around this, adjust the period specification in the constraint file so that it is divisible by the factors used on the DCM, leaving no sub-picosecond remainders.

For more complicated clocking regimes where the source period cannot be divided into multiple DCM output PERIODs without remainders, a work-around using a FROM:TO constraint can be used.

This issue generally affects cross-clock domain paths, so setting up a FROM:TO constraint between the clocks that have these large periods might fix the problem.

*For example*:

#Group elements by clock

NET "clkfx_out" TNM_NET = "clkfx_grp";

NET "clkdv_out" TNM_NET = "clkdv_grp";

#FROM TO cross-clock domain paths

TIMESPEC "TS_clkfx2clkdv" = FROM "clkfx_grp" TO "clkdv_grp" 20 ns;

TIMESPEC "TS_clkdv2clkfx" = FROM "clkdv_grp" TO "clkfx_grp" 20 ns;

In the 5.1i software, the rounding difficulties are solved by a solution that eliminates the rounding problem for the most common use cases. This resolution summarizes those cases in which the solution will work and those cases in which problems will or might still occur.

**Correct Cases (where the solution should work successfully without any user intervention)**

- Cases in which the original period and the derived period are both "nice" numbers (a "nice" number being one expressed in ps without requiring sub-ps precision).

For example, a period of 10000 ps and a derived constraint of 2X (period = 5000 ps) will work correctly.

Counterexample: A period of 10000 ps and a derived constraint of 7X (period 1428.__57__ ps) will not work because the derived period is not "nice" (has sub-ps precision).

- Attempt to keep the original period confined to even numbers to yield the best chance of avoiding a rounding error.

- Given an **even, "nice" number** as the original period, the following hints can be utilized:

--- A derived period that is an **integer multiple** of the original period should produce valid results.

*For example*:

Original = 10000 ps, Derived = 20000 ps (1/2 X = **2 times the period**).

--- A derived period that is an **"integer plus 1/2" multiple** of the original period should produce valid results.

*For example*:

Original = 10000 ps, Derived = 15000 ps (2/3 X = **1.5 times the period**).

--- Certain "integer plus non-repeating decimal" combinations for the derived period __might__ work. However, no concrete rules apply to this, as it depends upon the original period. To determine applicable cases, consult the step-by-step list below regarding a mod that has a threshold of less than 2 ps.

--- Certain "integer plus repeating decimal" combinations for the derived period __might__ work. Again, this depends upon the original period; for exact details, consult the step-by-step list below regarding a mod that has a threshold of less than 2 ps.

- Given an **odd, "nice" number** as the original period, the following hints can be utilized:

--- A derived period that is an **integer multiple** of the original period should produce valid results.

*For example*:

Original = 3333 ps, Derived = 6666 ps (1/2 X = **2 times the period**).

--- Other cases depend upon the original period value and the derived factor. For exact details, consult the step-by-step list below regarding a mod that has a threshold of less than 2 ps.

- Cases in which the original period is "nice" and the derived is "not nice", where the modulus of the two is less than the threshold of 2 ps.

__To determine whether a given example qualifies, perform the following step-by-step procedure:__

--- Apply the derived factor to the original period (in ps) to arrive at the derived period, which should also be in ps (.i.e., a 10000 ps original with a 3X creates a derived period of 3333.333333.... ps).

--- Truncate the derived period (remove the decimal portion; i.e., 3333 ps).

--- Determine the remainder of the larger period divided by the smaller period (using the truncated values arrived upon in the last step). For example, 10000 / 3333 = 3333 with remainder 1 ps.

If the remainder is 2 ps or less, it will behave correctly. If the remainder is greater than 2 ps, it will not behave correctly.

**Incorrect Cases (in which the solution will fail)**

- Cases in which the modulus of the two periods is greater than the threshold of 2 ps. To determine whether this is the case, follow the procedure described in the step-by-step list above.

- Note that for many cases in which the derived period is larger than the original period, the modulus will be larger than 2 ps, so the tools will fail.

For example, an original period of 3333 ps and a derived period of 4999 ps (2/3 X = period 1.5 times original period) fails because the mod of the larger divided by the smaller is 1666 ps (much greater than the 2 ps threshold).

In this case, use FROM:TO constraints between these clock domains.

Was this Answer Record helpful?

AR# 12174 | |
---|---|

Date Created | 08/29/2007 |

Last Updated | 01/18/2010 |

Status | Archive |

Type | General Article |