cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
462 Views
Registered: ‎12-12-2019

Place 30-674 - Error upon adding a clock

Jump to solution

I have a design I'm porting from one project to another that has a lot of clocks in it.  There was one clock we hadn't connected before, and implentation was working. (we'd temporarily connected that clock to a different one).  Now I added that clock at the proper frequency (generated by an existing MMCM, using an additional output) and I'm getting the error below.   Is it safe to use CLOCK_DEDICATED_ROUTE false here?

The clocking structure is as follows:

a 30.72 MHz input reference clock drives an MMCM that produces 491.52 and 245.76.  The 245.76 feeds bufgce_divs to generate 122.88 and skew-compenated 30.72.

The skew-compensated 30.72 drives a second MMCM that produces 320, 240, and 288 (288 is the new one).  bufgce_divs on the 320 are used to generate 160 and 80.

The skew-compensated 30.72 also drives a third MMCM that produces 352.  bufgce_divs on the 352 are used to generate 176, 88, and 44.

Separate from those clocks, there's a 300Mhz reference coming in that goes to a 4th MMCM which generates 300 and 200.  The 200 goes to bufgce_divs to make 100 and 50.

 

Is it just too many different clocks to handle?  Is safe to use CLOCK_DEDICATED_ROUTE FALSE here?

Full original error message follows...

---------------------------

 

[Place 30-674] Sub-optimal placement for an MMCM-BUFG component pair.If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.
< set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets wifi_clk_generation/mmcm0_clk_out0] >

wifi_clk_generation/MMCME4_BASE_inst (MMCME4_ADV.CLKOUT0) is provisionally placed by clockplacer on MMCM_X0Y7 (in SLR 1)
wifi_clk_generation/BUFG320_inst (BUFGCE_DIV.I) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y18 (in SLR 1)
wifi_clk_generation/BUFGCE_DIV_CLK_160 (BUFGCE_DIV.I) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y19 (in SLR 1)
wifi_clk_generation/BUFGCE_DIV_CLK_80 (BUFGCE_DIV.I) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y29 (in SLR 1)

The above error could possibly be related to other connected instances. Following is a list of
all the related clock rules and their respective instances.

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
iClkGenFromAux/BUFGCE_DIV_122_88 (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y26 (in SLR 1)

Clock Rule: rule_mmcm_bufg
Status: PASS
Rule Description: A MMCM driving a BUFG must be placed in the same clock region of the device as the
BUFG
iClkGenFromAux/MMCME3_30_72 (MMCME4_ADV.CLKOUT1) is provisionally placed by clockplacer on MMCM_X0Y6 (in SLR 1)
iClkGenFromAux/BUFGCE_DIV_122_88 (BUFGCE_DIV.I) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y26 (in SLR 1)
iClkGenFromAux/BUFGCE_DIV_245_76 (BUFGCE_DIV.I) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y25 (in SLR 1)
iClkGenFromAux/BUFGCE_DIV_30_72 (BUFGCE_DIV.I) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y24 (in SLR 1)

Clock Rule: rule_bufg_mmcm
Status: PASS
Rule Description: A BUFGCE with MMCM driver driving an MMCM must be in the same CMT column, and they
are adjacent to each other (vertically) if CLOCK_DEDICATED_ROUTE=BACKBONE is NOT set.
iClkGenFromAux/BUFGCE_DIV_30_72 (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y24 (in SLR 1)
iClkGenFromAux/MMCME3_30_72 (MMCME4_ADV.CLKFBIN) is provisionally placed by clockplacer on MMCM_X0Y6 (in SLR 1)
wifi_clk_generation/MMCME4_BASE_inst (MMCME4_ADV.CLKIN1) is provisionally placed by clockplacer on MMCM_X0Y7 (in SLR 1)
wifi_clk_generation/MMCME4_clk_352mhz_inst (MMCME4_ADV.CLKIN1) is provisionally placed by clockplacer on MMCM_X0Y5 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
iClkGenFromAux/BUFGCE_DIV_30_72 (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y24 (in SLR 1)

Clock Rule: rule_gclkio_mmcm
Status: PASS
Rule Description: An IOB driving an MMCM must use a GCIO in the same bank of the device as the MMCM
iClkGenFromAux/IBUFDS_CLK/IBUFCTRL_INST (IBUFCTRL.O) is locked to IOB_X0Y333 (in SLR 1)
iClkGenFromAux/MMCME3_30_72 (MMCME4_ADV.CLKIN1) is provisionally placed by clockplacer on MMCM_X0Y6 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
iClkGenFromAux/BUFGCE_DIV_245_76 (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y25 (in SLR 1)

Clock Rule: rule_mmcm_bufg
Status: PASS
Rule Description: A MMCM driving a BUFG must be placed in the same clock region of the device as the
BUFG
wifi_clk_generation/MMCME4_BASE_inst (MMCME4_ADV.CLKOUT1) is provisionally placed by clockplacer on MMCM_X0Y7 (in SLR 1)
wifi_clk_generation/BUFG240_inst (BUFGCE_DIV.I) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y28 (in SLR 1)

Clock Rule: rule_mmcm_bufg
Status: PASS
Rule Description: A MMCM driving a BUFG must be placed in the same clock region of the device as the
BUFG
wifi_clk_generation/MMCME4_clk_352mhz_inst (MMCME4_ADV.CLKOUT0) is provisionally placed by clockplacer on MMCM_X0Y5 (in SLR 1)
iTechnologyTop/iTechnologyComponent/kt_cwag_framework/kt_cwag_clocking/bufgce_sys_clk352 (BUFGCE.I) is provisionally placed by clockplacer on BUFGCE_X0Y142 (in SLR 1)
wifi_clk_generation/BUFGCE_DIV_CLK_176 (BUFGCE_DIV.I) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y21 (in SLR 1)
wifi_clk_generation/BUFGCE_DIV_CLK_44 (BUFGCE_DIV.I) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y20 (in SLR 1)
wifi_clk_generation/BUFGCE_DIV_CLK_88 (BUFGCE_DIV.I) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y23 (in SLR 1)
wifi_clk_generation/BUFG_CLK_352_inst (BUFGCE.I) is provisionally placed by clockplacer on BUFGCE_X0Y120 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
wifi_clk_generation/BUFG320_inst (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y18 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
wifi_clk_generation/BUFGCE_DIV_CLK_160 (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y19 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
wifi_clk_generation/BUFGCE_DIV_CLK_80 (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y29 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
wifi_clk_generation/BUFG240_inst (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y28 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
wifi_clk_generation/BUFG288_inst (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y30 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
iTechnologyTop/iTechnologyComponent/kt_cwag_framework/kt_cwag_clocking/bufgce_sys_clk352 (BUFGCE.O) is provisionally placed by clockplacer on BUFGCE_X0Y142 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
wifi_clk_generation/BUFGCE_DIV_CLK_176 (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y21 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
wifi_clk_generation/BUFGCE_DIV_CLK_44 (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y20 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
wifi_clk_generation/BUFGCE_DIV_CLK_88 (BUFGCE_DIV.O) is provisionally placed by clockplacer on BUFGCE_DIV_X0Y23 (in SLR 1)

Clock Rule: rule_bufgce_bufg_conflict
Status: PASS
Rule Description: Only one of the 2 available sites (BUFGCE or BUFGCE_DIV/BUFGCTRL) in a pair can be
used at the same time
and wifi_clk_generation/BUFG_CLK_352_inst (BUFGCE.O) is provisionally placed by clockplacer on BUFGCE_X0Y120 (in SLR 1)

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
307 Views
Registered: ‎01-22-2015

kron.laufer@keysight.com 

Thanks for very clear answers to the questions.

From Table 9 of DS890(v3.11) I find that the XCVU13P has 16ea MMCMs, which implies 64ea BUFGCE_DIVs.   So, there should be plenty of clocking hardware to do what you want. 

As I mentioned in my first response, Vivado will complain if you try to connect more that 4ea BUFGCE_DIVs to the output of each MMCM.  For all four of your MMCMs, you can satisfy the “4ea BUFGCE_DIV” restriction using the suggestions from Avrum.   That is, don’t cascade the clock buffers and, when possible, use the BUFGCE instead of the BUFGCE_DIV.

Fig 79 in UG949(v2019.2) shows how the output of an MMCM can directly drive parallel BUGCE_DIVs - and the text near this figure describes advantages of doing this.  Note also the IMPORTANT note near Fig 79 that describes alignment of parallel BUFGCE_DIVs.

Also, based on what you’ve told us, you don’t need to check “Phase Alignment” in the Clocking Wizard for the MMCMs.   When you use “Phase Alignment” a clock buffer is connected between ports CLKFBIN and CLKFBOUT of the MMCM.  So, using “Phase Alignment” when it is not needed will unnecessarily use a clock buffer (sometimes a BUFGCE_DIV), which you cannot afford.

So, try these BUFGCE_DIV saving measures and see if Vivado can then place and route your clocking network with throwing the “sub-optimal placement” errors at you.

View solution in original post

Tags (1)
6 Replies
Highlighted
421 Views
Registered: ‎01-22-2015

ron.laufer@keysight.com 

For your UltraScale device, each clocking region (CR) contains 4ea BUFGCE_DIVs and 1ea MMCM (ref pages 16 and 8 of UG572(v1.9)).   As described in Table 4 of UG949(v2019.2), Vivado tries to place an MMCM and its associated output clock buffers in the same CR.  When this cannot be done, then Vivado gives the sub-optimal placement warning that you are seeing and suggests possible use of the CLOCK_DEDICATED_ROUTE constraint.   Since you have so many MMCMs and BUFGCE_DIVs, then I think this is the issue and the explanation for the warning you are seeing.

Is it just too many different clocks to handle?
No.  UG572 suggest that up to 24 different clocks are possible. 

 

Is safe to use CLOCK_DEDICATED_ROUTE FALSE here?
That depends....  Please answer the following questions:

  1. The warning suggest that you set CLOCK_DEDICATED_ROUTE FALSE on  “wifi_clk_generation/mmcm0_clk_out0”.   Which MMCM and clock in your verbal description is “wifi_clk_generation/mmcm0_clk_out0”?

  2. Are you using LOC constraints to lock any clocking components into specific locations – or are you letting implementation freely choose their locations in the FPGA? 

  3. Can you tell me which clock pairs you expect to be synchronous with each other (as opposed to be asynchronous with each other)?

  4. Do you have any “set_clock_groups -async” constraints in your design?
  5. What is the part# for your FPGA?


Cheers,
Mark

Highlighted
347 Views
Registered: ‎12-12-2019

Hi Mark, Thanks for the quick reply.  To answer your questions:

1. wifi_clk_generation/mmcm0_clk_out0 is the 320Mhz CLKOUT0 of the "second MCMM" in my description. The MMCM's input is the skew-compensated 30.72, and its outputs are: 320, 240, and 288.   mmcm0_clk_out0 drives 3 bufgce_divs, to create 320, 160, and 80Mhz internal clocks.  The bufgce_divs then each drive a BUFGCE and those BUFGCE outputs are what we ultimately use as our clocks.   (Would it help to have a single bufgce_div on each rather than cascading bufgce_div and bufgce?  The reason for the separation is legacy project structure.  I could theoretically break the structure to combine them)

2. no loc constraints for the clock components.  the only LOC constrainsts are for GTYE4_CHANNELS and SYS_MONE

3. we expect 4 synchronous groups:  the 320,160,80 to be synchronous to each other, the 352,176,88,44 group, the 200,100,50 group, and the 491.52,245.76,122.88,30.72 group.  The 300,240, and 288 are not expected to be synchronous to anything.

4. I do not see any "set_clock_groups -async", though I do see: "set_property CLOCK_DELAY_GROUP" on the 200-50 group and the 320-80 group.  (should I put these on the other 2 groups as well? I'm guessing yes)

5.xcvu13p-figd2104-2L-e

 

0 Kudos
Highlighted
Guide
Guide
336 Views
Registered: ‎01-23-2009

Would it help to have a single bufgce_div on each rather than cascading bufgce_div and bufgce

You should (almost) never cascade global buffers. Each BUFG* primitive (whether it is a BUFGCE, BUFGCE_DIV or BUFGCTRL) has a dedicated connection to the global clocking network; so there is no need to cascade them from a connectivity point of view. Furthermore, each of these primitives is "equivalent" in terms of delay and connectivity, so you can mix and match them and still get low skew results. So for example, for your first MMCM CLKOUT0, which is generating 320, 160, and 80MHz, you can use a BUFGCE for the 320MHz clock and a BUFGCE_DIV for the 160 and 80MHz clocks, thus using more BUFGCE (which you have 24 per clock region) and fewer BUFGCE_DIV (which you only have 4).

You must also be careful with the CLOCK_DELAY_GROUP attributes; for the "related" clocks (i.e. the 320, 160 and 80) if you plan to cross synchronously between these domains, they should be in the same CLOCK_DELAY_GROUP.

Avrum

Tags (1)
Highlighted
308 Views
Registered: ‎01-22-2015

kron.laufer@keysight.com 

Thanks for very clear answers to the questions.

From Table 9 of DS890(v3.11) I find that the XCVU13P has 16ea MMCMs, which implies 64ea BUFGCE_DIVs.   So, there should be plenty of clocking hardware to do what you want. 

As I mentioned in my first response, Vivado will complain if you try to connect more that 4ea BUFGCE_DIVs to the output of each MMCM.  For all four of your MMCMs, you can satisfy the “4ea BUFGCE_DIV” restriction using the suggestions from Avrum.   That is, don’t cascade the clock buffers and, when possible, use the BUFGCE instead of the BUFGCE_DIV.

Fig 79 in UG949(v2019.2) shows how the output of an MMCM can directly drive parallel BUGCE_DIVs - and the text near this figure describes advantages of doing this.  Note also the IMPORTANT note near Fig 79 that describes alignment of parallel BUFGCE_DIVs.

Also, based on what you’ve told us, you don’t need to check “Phase Alignment” in the Clocking Wizard for the MMCMs.   When you use “Phase Alignment” a clock buffer is connected between ports CLKFBIN and CLKFBOUT of the MMCM.  So, using “Phase Alignment” when it is not needed will unnecessarily use a clock buffer (sometimes a BUFGCE_DIV), which you cannot afford.

So, try these BUFGCE_DIV saving measures and see if Vivado can then place and route your clocking network with throwing the “sub-optimal placement” errors at you.

View solution in original post

Tags (1)
Highlighted
267 Views
Registered: ‎12-12-2019

OK, I have attempted to replace the cascaded BUFGCE_DIV and BUFGCE with a single BUFGCE_DIV for each clock.  I have a structure now that looks very similar to that Figure 79, except with 4 BUFGCE_DIVs instead of 2, and I have all the outputs of the BUFGCE_DIVs from the same MMCM output in a CLOCK_DELAY_GROUP.

Things seem to be working on this front for the moment, (thank you!) but I'm running into another issue, posted here:

https://forums.xilinx.com/t5/Synthesis/Vivado-inserting-backslashes-in-clock-names-then-not-escaping/td-p/1116704

0 Kudos
Highlighted
Moderator
Moderator
198 Views
Registered: ‎01-16-2013

ron.laufer@keysight.com 

 

Can you please close this thread if the initial query has been addressed? Mark the post which was helpful as "Accept as solution"

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos