cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
7,517 Views
Registered: ‎02-04-2015

[Place 30-367] Global clock constraining failed to constrain instance

I am seeing the following INFO followed by an error. I assume the former is the cause of the latter.

 

[Place 30-367] Global clock constraining failed to constrain instance modified_gtwizard_wrapper_e/gtwizard_ultrascale_e/gtwizard_ultrascale_0_inst/inst/gen_gtwizard_gtye3_top.gtwizard_ultrascale_0_gtwizard_gtye3_inst/gen_gtwizard_gtye3.gen_reset_controller_internal.gen_single_instance.gen_rxuserclkactive_per_channel_instance.gen_ch_rxclk[0].bit_synchronizer_gtwiz_reset_userclk_rx_active_inst/i_in_meta_reg to clock region CLOCKREGION_X4Y3. Instance already belongs to an area constraint group, which does not intersect with the proposed clock region..

 

[Place 30-99] Placer failed with error: 'Unable to recover shape constraints after disabling added constraints due to shape constraint generation failure'
Please review all ERROR, CRITICAL WARNING, and WARNING messages during placement to understand the cause for failure.

 

The register i_in_meta_reg is part of a synchroniser chain, clocked by the following chain, which connects to gtwiz_reset_clk_freerun_in on gtwizard_ultrascale_0_inst:

 

Vivado Clock Screenshot.png

 

It seems plausible that the reset synchroniser may be constrained to CLOCK_REGION_X0Y0 as part of the gtwizard instantiation (though I can't find an explicit AREA constraint anywhere). The input refclk100_clk_p is in CLOCK_REGION_X4Y3, but I thought that the output of BUFG_GT the clock should be able to reach it given that it is a GLOBAL_CLOCK net.

 

(I think the BUFG in the above tree is redundant, but removing it does not help to resolve my problem)

 

Is there another step required to promote the clock to global routing?

 

0 Kudos
2 Replies
Highlighted
Xilinx Employee
Xilinx Employee
7,305 Views
Registered: ‎08-01-2012

Which version of Xilinx (ISEXX/Vivado XX) tools are you using? 

 

FYI: When more BUFG components are required, pin selection and placement must be considered in order to avoid any possibility of contention of resources based on global clocking line contention, placement of clock loads, or both

________________________________________________

Please mark this post as an "Accept as solution" in case if it helped to resolve your query. So that it will help to other forum users to directly refer to the answer.

Give kudos to this post in case if you think the information is useful and reply oriented.

0 Kudos
Highlighted
Observer
Observer
7,260 Views
Registered: ‎02-04-2015

We are using Vivado 2015.4

 

Since my original post I have started from scratch with the gtwizard_ultrascale_0_example reference design, adding back all the other components that were in the design giving me the problem initially. This includes some custom IP which we have packaged up for use in IP integrator. I have an identical tcl script which generates the block design in both projects. This new project synthesises and implements without any errors, and the bitstream works.

I am now trying to copy the working project back to the old source tree, so that I can have a working version in our git repository.

In order to do this, I used the "Write Project TCL" command from the working project, and manually edited the absolute paths to point to the relative source locations in our main source tree. I also commented out the VIO core instance.

When I source this script, I see exactly the same INFO and ERROR messages as previously reported!

The only thing that I can think of is that this has something to do with the order of constraint processing.
I have compared the output of "write_xdc test.xdc" from both projects and do not see any differences between them other than constraints for the ILA and VIO cores which are not present in the broken project.

Any other ideas?

 

 

0 Kudos