Strange way to route design.

Hello, colleagues.
I'm fixing issues of the design with many clocks and its interaction on Art=
ix7 FPGA. In order to move data from one clock domain to another I'm using =
double-port distributed memory with synchronous read, but this design doesn=
't meet timing constrains (250Mhz). Critical path consists of a trigger of =
the read address of the Distributed RAM, a Distributed Ram primitive and a =
Read data trigger. This route has total slack -3 ns. This two triggers are =
in neighbour slices of each other and RAM primitive is a few slices apart o=
f them and all should look good.
But route report of Vivado tool displays that source clock (of address trig=
ger) has delay of 6 ns, destination clock (of data trigger) has delay of 10=
 ns (that is strange - it's neighbour slice) and to meet this timing the to=
ol route the path from RAM primitive to destination flop throughout entire =
FPGA and ends up with 13 ns delay which is 3 ns more then it should be.
Here are my questions:
1. why 2 triggers (having the same clock and placed in neighbour slices) ha=
ve such a big difference of clock arrival time (6 and 10 ns)?
2. Why routing tool can't find a path with arrival time of 10 ns when it ha=
ve found path with 13 ns and FPGA is almost free now?
3. How can I solve this problem?
4. Is there any document to read how to manage with such kind of problems?

May be it's important:
there is a lot of different clocks in design derived from one source and most of clock boundary crossings are timed i.e. designer implied that design tool could manage to make this crossing safe. I think that this big difference of clock arrival time is may be caused by attempts of vivado to meet requirements of such clock crossing. But I'm not sure.

On Tuesday, August 11, 2015 at 5:17:48 PM UTC-4, Ilya Kalistru wrote:
> May be it's important:
> there is a lot of different clocks in design derived from one source and =
most of clock boundary crossings are timed i.e. designer implied that desig=
n tool could manage to make this crossing safe. I think that this big diffe=
rence of clock arrival time is may be caused by attempts of vivado to meet =
requirements of such clock crossing. But I'm not sure.

Are these clocks only from a clock input pin of the device, or the output o=
f a PLL/DLL?  Or are these clocks generated from logic (either gates or fli=
p flop outputs)?  If these are generated clocks, there is your problem.

Kevin Jennings

One clock is an output clock of PCIe block and other are derived from it by MMCM. Nothing wrong here.  No gating clocks,  no logic on the clock path. 

There was a lot of different clocks in design derived from one source and most of clock boundary crossings are timed i.e. designer implied that design tool could manage to make this crossing safe.
It looks like this phenomenon was caused by attempts of vivado to meet requirements of crossing interclock boundary.

After I got rid of all clock crossings that is not through "false path" this huge clock skew disappeared and now all right.