1. Home
  2. Field-Programmable Gate Arrays
  3. Strange way to route design.

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?
Reply to
Ilya Kalistru
Loading thread data ...

May be it's important: there is a lot of different clocks in design derived from one source and mo st 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 differe nce of clock arrival time is may be caused by attempts of vivado to meet re quirements of such clock crossing. But I'm not sure.

Reply to
Ilya Kalistru

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

Reply to
KJ

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.

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

Reply to
Ilya Kalistru

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.