Strange way to route design.

[Ilya Kalistru]

Hello, colleagues.
I'm fixing issues of the design with many clocks and its interaction on Artix7 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 of them and all should look good.
But route report of Vivado tool displays that source clock (of address trigger) 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 tool 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) have 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 have 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?

 

[Ilya Kalistru]

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.

 

[KJ]

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 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.

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

Kevin Jennings

 

[Ilya Kalistru]

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.

 

[Ilya Kalistru]

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.