UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
125 Views
Registered: ‎04-01-2016

Timing constraints for BUFGMUX + PLL

Hi all,

this is a follow up for the following post: Timing problems when adding second clock

2018-12-12_15h38_18.pngSchematic

As you can see in the above post there are two clocks (fosc_clk and sync_clk) going to the BUFGCTRL. I added the following timing constraints:

# rename the clock which is used for the first input for the clock control
create_generated_clock -name fosc_clk_clock [get_pins MainClocking_inst/inst/mmcm_adv_inst/CLKOUT0]
    
create_generated_clock -name fosc_clk_mux -divide_by 1 -add -master_clock fosc_clk_clock -source [get_pins fpga_asic_dummy_inst0/rcm_i/rcm_pd1_clk_ctrl_i/BUFGMUX_CTRL_inst/I0] [get_pins fpga_asic_dummy_inst0/rcm_i/rcm_pd1_clk_ctrl_i/BUFGMUX_CTRL_inst/O]
create_generated_clock -name sync_clk_mux -divide_by 1 -add -master_clock sync_clk_clock -source [get_pins fpga_asic_dummy_inst0/rcm_i/rcm_pd1_clk_ctrl_i/BUFGMUX_CTRL_inst/I1] [get_pins fpga_asic_dummy_inst0/rcm_i/rcm_pd1_clk_ctrl_i/BUFGMUX_CTRL_inst/O]
set_clock_groups -physically_exclusive -group fosc_clk_mux -group sync_clk_mux

When I do have a look at the input of the PLL following the BUFGCTRL (get_clocks -of_object [get_pins PLL_INPUT]) I get back the following which is absolutely correct according to my opinion:

fosc_clk_mux sync_clk_mux

But after the PLL I get for all the outputs the multiple_clock warning and a timing report which is the worst I've ever seen. As you can see in the timing constraints above I set the two clock networks to physically exclusive so there shouldn't be a problem at the input of the PLL.

I tried the following: removing the BUFGCTRL as clock multiplexer and using the second input of the PLL itself:

2019-01-08_09h34_25.png

Synthesis is working as expected but I get an error in implementation:

2019-01-08_09h07_34.png

 

I tried to solve this error with the help of the following post: DRC REQP-119 but without any success.

So perhaps this is exactly the same problem when using the BUFGCTRL? I mean that perhaps the timing constraints are correct for just the multiplexer, but the PLL does have some problems with the clock multiplexing?

It is really important to me not just solve that problem with the help of some constraints but to understand what's going on here, where the specific problems are and how they can be avoided in the next project / module ....

Thank you so much for helping me on this issue!

Kind regards

Sebastian

 

0 Kudos
1 Reply
Historian
Historian
82 Views
Registered: ‎01-23-2009

Re: Timing constraints for BUFGMUX + PLL

I'm not sure if this will fix it, but try:

set_clock_groups -physically_exclusive -group [get_clocks -include_generated_clocks fosc_clk_mux] -group [get_clocks -include_generated_clocks sync_clk_mux]

Avrum

0 Kudos