Can Clocks be put onto local routing?

[richardhead]

During implementation, I get the following warning:

CRITICAL WARNING: [Place 30-852] Cannot find an available clock routing track for clock net <clk2> in its partition defined by a rectangle from clock region X2Y3 to clock region X2Y9. A clock partition is a rectangular area covering all clock loads and the clock region for its clock root. It may cover the clock source as well. Each clock net needs to use the same routing track across all clock regions of its partition. In this case, other clock nets are already using resources in one or more clock regions of this partition.
This issue is most likely due to the requirement that two or more clock nets need to use global clocking resources in the same half clock region (top/bottom), but this failed due to existing constraints on other clock sources that are placed in that clock region (X2Y9). List of clock nets involved:
<clk1>
<clk2>

<clk1> and <clk2> are used only for clocking ouput DDR registers. For CLK1, this is 8 regs, and CLK2 it is a single DDR reg, so I dont think these really need to use dedicated clock routing? The design is already heavily congested and the addition of some of the clocks in this region (which mostly have low fanout) have knock-on effects with unrelated parts of the design (probably because they're using the dedicated clock routing locking other parts of the design out of the region).

Whats the easiest way to handle these clocks so they have minimal impact elsewhere?

CLK1 and CLK2 come directly a MMCM and are MUXed with another clock in the design.

NOTE: This is for an Ultrescale+

[klasha]

How are you Muxing the Clocks? You should use a construction with BUFGMUX, BUFGCTRL or similar. If you are muxing in straight vhdl/verilog, you are forcing the mux into regular logic. 

Whether your design works with clocks in local routing depends on your requirements. But you usually should avoid doing that if at all possible. 

[richardhead]

Yes, they are all muxed with BUFGCTRL. The issue is that the MUXes only exist in a single column on the device, and the ones it selects are in the middle of a large block of logic that belong to a large Xilinx IP (it choses to place here). If it moves this IP because the clock muxes take the routing, it then fails timing.

[surajc]

Hi @richardhead ,

What are the fanout's of these two clocks?

If the fanout of either the clocks is low, can you try CLOCK_LOW_FANOUT on the loads and see if it helps?

Which vivado version are you using?

Can you share the schematic of the clock connections?

This will help us understand the issue better.

[richardhead]

@surajc 

This is vivado 2019.2

Here is the clocking schematic:

Here, the 74.25Mhz has a fanout of 11 endpoints and the 74.25Mhz 90 has 4 endpoints. The Clock muxes selected are surrounded by a 25G Xilinx MAC IP, and this often causes timing failures (~500 -1000) in the FEC block in the MAC.

If I remove the 27MHz clock from the design, it routes successfully.

[viviany]

Do you have any pblock for the logics around this BUFGMUX?

Do the 74M25 and 74M25 90 clock occupy another BUFGs besides the BUFGMUXes? (which means BUFG and BUFGMUX in serial)

A low fanout and low frequency clock can be put on local routing. But if you put a BUFGMUX on the clock net, it has to go on global clock routing.

-vivian

[markg@prosensing.com]

@richardhead 

Do you have any "set_property CLOCK_DELAY_GROUP"  constraints in your design?

If you are putting this constraint on large groups of clocks or using it unnecessarily then the clock placer is stressed (ref page 119, UG949(v2019.2)).  Sound familiar?

Unless you are crossing data synchronously between the clock domains, try not using (or reducing use of) "set_property CLOCK_DELAY_GROUP" constraints -  and see if your design routes completely and passes timing analysis.

Mark

[richardhead]

@viviany 

No pblocks at all in the design. The MMCM has BUFGs on these 74Mhz clocks, other than that no other items on the clocks.

markg@prosensing.com 

There is one CLOCK_DELAY_GROUP in an unrelated and unaffected part of the design. It is the only one in the design.

Overall the chip is at 60% utilisation. There are 43 clocks in the design overall (Alot are within the GTY/GTHs)

[markg@prosensing.com]

@richardhead 

It sounds like the 24 routing tracks in a clocking region (CR) of your UltraScale+ device are full (ref UG572, page 16).  

Perhaps you can use the CLOCK_REGION constraint (page 100, UG949) to move the BUFGCTRLs/BUFGMUXs (or other (eg. MMCM) clocking components) to another less-congested CR.   Since your clocks (74 MHz and 27 MHz) are fairly slow, this should not significantly affect timing for these clock domains.