Return to Question

I used Vivado to synthesize a small design for the Xilinx xc7k-160t-1. The design includes a fifo instantiated with Vivado's XPM macros which crosses clock domains from 100.8MHz to 200MHz.

When I opened the synthesized design, I saw these extremely long nets that used routing resources for no apparent purpose; the start and end of the nets are in adjacent cells, but they're routed way out to the edges of the chip! There are about 20 of them; I think they're connected to the gray counters in the CDC fifos.

Does anyone know why Vivado synthesizes these extremely long nets?

I have a guess about why these are here - I've failed to explain the relationship between my two clocks properly to Vivado. I think its routing optimizer might be getting stuck in some weird local minima (I have negative slack in my inter-clock timing table, but I don't think I need to be worried about that because my CDC is handled through the fifo in question). I'd like a more definitive answer though. Googling hasn't turned up anything yet.

My design is deployed to an Opal Kelly xem7360 module. The xdc/sdc file for this module can be downloaded here, but the snippet relevant to my clocks is below:

create_clock -name okUH0 -period 9.920 [get_ports {okUH[0]}] create_clock -name sys_clk -period 5 [get_ports sys_clkp] set_clock_groups -asynchronous -group [get_clocks {sys_clk}] -group [get_clocks {okUH0}] 

One of my clock domains is the 100.8MHz okUH[0] clock, the other is the 200MHz sys_clk.

I can add a minimal reproducible example to my question if people want.

I used Vivado to synthesize a small design for the Xilinx xc7k-160t-1. The design includes a fifo instantiated with Vivado's XPM macros which crosses clock domains from 100.8MHz to 200MHz.

When I opened the synthesized design, I saw these extremely long nets that used routing resources for no apparent purpose; the start and end of the nets are in adjacent cells, but they're routed way out to the edges of the chip! There are about 20 of them; I think they're connected to the gray counters in the CDC fifos.

My question: Does anyone know why Vivado synthesizes these extremely long nets? Is there a reason that Vivado is doing this intentionally, or is it a sign of an issue in my design / constraints?

My design is deployed to an Opal Kelly xem7360 module. The xdc/sdc file for this module can be downloaded here, but the snippet relevant to my clocks is below:

create_clock -name okUH0 -period 9.920 [get_ports {okUH[0]}] create_clock -name sys_clk -period 5 [get_ports sys_clkp] set_clock_groups -asynchronous -group [get_clocks {sys_clk}] -group [get_clocks {okUH0}] 

One of my clock domains is the 100.8MHz okUH[0] clock, the other is the 200MHz sys_clk.

I can add a minimal reproducible example to my question if people want.

I used Vivado to synthesize a small design for the Xilinx xc7k-160t-1. The design includes a fifo instantiated with Vivado's XPM macros which crosses clock domains from 100.8MHz to 200MHz.

When I opened the synthesized design, I saw these extremely long nets that used routing resources for no apparent purpose; the start and end of the nets are in adjacent cells, but they're routed way out to the edges of the chip! There are about 20 of them; I think they're connected to the gray counters in the CDC fifos.

Does anyone know why Vivado synthesizes these extremely long nets?

I have a guess about why these are here - I've failed to explain the relationship between my two clocks properly to Vivado. I think its routing optimizer might be getting stuck in some weird local minima (I have negative slack in my inter-clock timing table, but I don't think I need to be worried about that because my CDC is handled through the fifo in question). I'd like a more definitive answer though. Googling hasn't turned up anything yet.

I can add a minimal reproducible example to my question if people want.

I used Vivado to synthesize a small design for the Xilinx xc7k-160t-1. The design includes a fifo instantiated with Vivado's XPM macros which crosses clock domains from 100.8MHz to 200MHz.

When I opened the synthesized design, I saw these extremely long nets that used routing resources for no apparent purpose; the start and end of the nets are in adjacent cells, but they're routed way out to the edges of the chip! There are about 20 of them; I think they're connected to the gray counters in the CDC fifos.

Does anyone know why Vivado synthesizes these extremely long nets?

I have a guess about why these are here - I've failed to explain the relationship between my two clocks properly to Vivado. I think its routing optimizer might be getting stuck in some weird local minima (I have negative slack in my inter-clock timing table, but I don't think I need to be worried about that because my CDC is handled through the fifo in question). I'd like a more definitive answer though. Googling hasn't turned up anything yet.

My design is deployed to an Opal Kelly xem7360 module. The xdc/sdc file for this module can be downloaded here, but the snippet relevant to my clocks is below:

create_clock -name okUH0 -period 9.920 [get_ports {okUH[0]}] create_clock -name sys_clk -period 5 [get_ports sys_clkp] set_clock_groups -asynchronous -group [get_clocks {sys_clk}] -group [get_clocks {okUH0}] 

One of my clock domains is the 100.8MHz okUH[0] clock, the other is the 200MHz sys_clk.

I can add a minimal reproducible example to my question if people want.

I used Vivado to synthesize a small design for the Xilinx xc7k-160t-1. The design includes a fifo instantiated with Vivado's XPM macros which crosses clock domains from 100.8MHz to 200MHz.

When I opened the synthesized design, I saw these extremely long nets that used routing resources for no apparent purpose; the start and end of the nets are in adjacent cells, but they're routed way out to the edges of the chip! There are about 20 of them; I think they're connected to the gray counters in the CDC fifos.

Does anyone know why Vivado synthesizes these extremely long nets?

I have a guess about why these are here - I've failed to explain the relationship between my two clocks properly to Vivado and its routing optimizer gets stuck in some weird local minima (I have negative slack in my inter-clock timing table, but I don't think I need to be worried about that as all my CDC is handled through fifos). I'd like a more definitive answer though. Googling hasn't turned up anything yet.

I can add a minimal reproducible example to my question if people want.

I used Vivado to synthesize a small design for the Xilinx xc7k-160t-1. The design includes a fifo instantiated with Vivado's XPM macros which crosses clock domains from 100.8MHz to 200MHz.

When I opened the synthesized design, I saw these extremely long nets that used routing resources for no apparent purpose; the start and end of the nets are in adjacent cells, but they're routed way out to the edges of the chip! There are about 20 of them; I think they're connected to the gray counters in the CDC fifos.

Does anyone know why Vivado synthesizes these extremely long nets?

I have a guess about why these are here - I've failed to explain the relationship between my two clocks properly to Vivado. I think its routing optimizer might be getting stuck in some weird local minima (I have negative slack in my inter-clock timing table, but I don't think I need to be worried about that because my CDC is handled through the fifo in question). I'd like a more definitive answer though. Googling hasn't turned up anything yet.

I can add a minimal reproducible example to my question if people want.