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: 
Highlighted
Explorer
Explorer
1,143 Views
Registered: ‎04-01-2016

Timing problems when adding second clock

Jump to solution

Hi all,

I do have a big problem with two clocks which are fed into a BUFGCTRL. They are not related to each other. The clock that causes the problem is called sync clock (see Schematic below). If I connect that clock to GND and just use the fosc_clk, everything is ok. The fosc_clk is derived from an PLL. The sync_clk is directly fed into the FPGA.

As soon as I add the connect the sync_clk to the real Pin all my timing is completely broken and I don't really why.

2018-12-12_15h38_18.pngSchematic

I added a clock group for the two clocks to let Vivado know that they are not related and I create a clock for the sync_clk. For the fosc_clk this is done for me because the clock is PLL-generated.

set_property PACKAGE_PIN Y22 [get_ports sync_clk]
#set_property PACKAGE_PIN R21 [get_ports sync_clk]
create_clock -period ${sync_clk_period} -name sync_clk_clock [get_ports sync_clk]
# set voltage level
set_property IOSTANDARD LVCMOS33 [get_ports sync_clk]

set_clock_groups -logically_exclusive  \
    - group [get_clocks -of_objects [get_pins fpga_asic_dummy_inst0/rcm_clk_ctrl_i/sync_clk]] \
    - group [get_clocks -of_objects [get_pins fpga_asic_dummy_inst0/rcm_clk_ctrl_i/fosc_clk]]

As told if I connect the sync_clk to GND everything is ok, but as soon as I connect to the Pin everything ends in an absolute disaster:

 

2018-12-12_15h43_23.png

The pin for the sync_clk is a dedicated clock pin (MRCC) so I really do not know what's going wrong here. I do have the feeling that I miss to set a timing constraint because when I add the sync_clk nothing is working and clocks which are totally fine with sync_clk <= '0' have timing problems. :(

I'm very glad for any help on this topic.

Kind regards

Sebastian

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
1,051 Views
Registered: ‎01-23-2009

Re: Timing problems when adding second clock

Jump to solution

My only concern is with the use of the -add option on the first of the two generated clocks on the BUFGMUX output. Done this way, it leaves the original clocks (which is both clocks) as well as the newly defined clocks - leaving 4 clocks total on this net. Given this, I am not sure why this doesn't create timing problems since you still have the two original clocks, which don't have an exclusive clock group on them..

The add is definitely needed on the second of the two, but it shouldn't be on the first.

You also don't need the -master_clock option - that is only needed if the -source carries more than one clock (which shouldn't be the case here).

So the constraints should be:

# 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      -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 -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
Tags (1)
11 Replies
Historian
Historian
1,130 Views
Registered: ‎01-23-2009

Re: Timing problems when adding second clock

Jump to solution

We need to see a detailed timing report of a failed path to help you with this.

Avrum

0 Kudos
Moderator
Moderator
1,121 Views
Registered: ‎11-04-2010

Re: Timing problems when adding second clock

Jump to solution

Hi, @sebastian_z ,

Hope the below constraint could be helpful. If not, please show us the detailed timing report as @avrumw requested.

set_clock_groups -physically_exclusive \
- group [get_clocks -of_objects [get_pins fpga_asic_dummy_inst0/rcm_clk_ctrl_i/sync_clk] -include_generated_clocks] \
- group [get_clocks -of_objects [get_pins fpga_asic_dummy_inst0/rcm_clk_ctrl_i/fosc_clk] -include_generated_clocks]

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Moderator
Moderator
1,079 Views
Registered: ‎01-16-2013

Re: Timing problems when adding second clock

Jump to solution

Hi,

As @avrumw mentioned you have shared very limited information to provide the suggestions. Please share the details on timing reports, clock interaction report and also the clock schematic.

I have one direct comment regarding the logically exclusive constraints. Looks like you are using clock-muxing and using primary clocks directly for constraining. Here you need to do following.

You need to generate two clocks (user generated clock definition) at the output pin of BUFGMUX using each input clocks. 

Now you have two clocks (generated clock definition) at the output pin of BUFGMUX and with those two clocks you need to specify the constraints as logically/physically exclusive (whatever falls under your use case).

For detailed understanding and syntax refer https://www.xilinx.com/support/answers/59484.html

Thanks,
Yash

Explorer
Explorer
1,064 Views
Registered: ‎04-01-2016

Re: Timing problems when adding second clock

Jump to solution

Hi @yashp @hongh and @avrumw,

thanks for the great help. I think with the link you sent me I managed to proceed. I try to include my whole clocking tree with the BUFGCTRL here:

2018-12-13_09h51_29.pngClocking Tree

With the link I added the following timing contraints:

# 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

Now the timing seems quite good. I have to to further analysis. If you need any further information please just let me know!

Kind regards

Sebastian

0 Kudos
Historian
Historian
1,052 Views
Registered: ‎01-23-2009

Re: Timing problems when adding second clock

Jump to solution

My only concern is with the use of the -add option on the first of the two generated clocks on the BUFGMUX output. Done this way, it leaves the original clocks (which is both clocks) as well as the newly defined clocks - leaving 4 clocks total on this net. Given this, I am not sure why this doesn't create timing problems since you still have the two original clocks, which don't have an exclusive clock group on them..

The add is definitely needed on the second of the two, but it shouldn't be on the first.

You also don't need the -master_clock option - that is only needed if the -source carries more than one clock (which shouldn't be the case here).

So the constraints should be:

# 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      -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 -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
Tags (1)
Explorer
Explorer
1,042 Views
Registered: ‎04-01-2016

Re: Timing problems when adding second clock

Jump to solution

Hi @avrumw,

thank you so much, this really looks good as you can see in the image below. To be honest I don't understand the -add switch, in more detail I don't understand why it is necessary in the second case but not in the first case. I think UG903 is a good source for that and I will try to understand with the help of UG903.

I do not expect that you explain it in every detail here, but perhaps you could give me a little hint. :)

Kind regards

Sebastian

2018-12-13_16h30_58.png

0 Kudos
Historian
Historian
1,034 Views
Registered: ‎01-23-2009

Re: Timing problems when adding second clock

Jump to solution

To be honest I don't understand the -add switch

By default, a net/pin/port can carry only one clock. This clock is either attached directly to the net/pin/port (with a create_clock or create_generated_clock) or is propagated to that net/pin from its driver, which ultimately leads to a create_clock or create_generated_clock on an upstream net/pin/port.

If you have a net/pin/port that already has a clock on it and you put a create_clock or create_generated_clock on that net/pin/port (without a -add) then the new clock removes the previous clock from that net pin port; the result is that everything upstream from that net/pin has the old clock and everything downstream from that net/pin (including the net/pin) has the new clock.

However, if you use the -add on the new clock, then this new clock is added to the net/pin without removing the older clock. Therefore, afterwards,  everything upstream from the net/pin has the old clock, and everything downstream (including the net/pin) has both clocks.

And this is what you want. For the output of the BUFGMUX, you want only the two new clocks (from the create_generated_clock commands) on the O output. So the first create_generated_clock should not have the -add option - this removes the two original clocks from the O pin and the downstream nets/pins, and places only the new clock (the one propagated from I0). Then the second create_generated_clock adds the second one (the one propagated by the I1) - but it needs the -add so that it doesn't remove the one from I0.

So now you have

  • Everything upstream of I0 has only fosc_clk_clock
  • Everything upstream of I1 has only sync_clk_clock
  • Everything downstream from O (including O) has both new clocks - fosc_clk_mux and sync_clk_mux

You then go and say that fosc_clk_mux and sync_clk_mux are physically exclusive.

This is exactly what you want. 

Take a look at this post on static timing analysis with MUXed clocks.

The output of your MUX has only fosc_clk_mux and sync_clk_mux, which are physically exclusive, so only paths 1 and 2 exist (3 and 4 have been removed by the clock groups). So that's good.

You also have to realize that all clocks in Vivado are related by default. Therefore, if there is a path from one of the un-muxed clock, say  sync_clk_clock to the MUXed clock, then the static timing analysis from the source FF @ sync_clk_clock to the destination FF @ sync_clk_mux is still considered a "synchronous" clock crossing, and the tool will handle it properly - the two clocks (sync_clk_clock and sync_clk_mux) have the same attributes and the same propagation paths, so they are "the same clock". Of course the path from sync_clk_clock to fosc_clk_mux (which is also on the destination path) will fail, since they are different clocks.

But fosc_clk_clock and sync_clk_clock are not physically exclusive. So, if, elsewhere in the design, there is a clock domain crossing (CDC) path between the two, you can properly constrain the CDC path. This is important. If, instead of defining fosc_clk_mux and sync_clk_mux, you had instead declared fosc_clk_clock and sync_clock_clk as different clock groups, then you would still be OK with all the paths on the MUXed clock, but you would now be unable to constrain this other CDC path - the set_clock_groups is the highest priority constraint and therefore prevents any other constraints between these clocks. Since most CDCs need constraints to function, your design would no be prone to failures due to an under-constrained CDC. Therefore all this effort is to ensure that you do not place the two original clocks in different clock groups...

Avrum

Explorer
Explorer
1,014 Views
Registered: ‎04-01-2016

Re: Timing problems when adding second clock

Jump to solution

@avrumw

That explanation helps me a lot! Thank you!

Kind regards

Sebastian

0 Kudos
Explorer
Explorer
964 Views
Registered: ‎04-01-2016

Re: Timing problems when adding second clock

Jump to solution

Hi @avrumw

unfortunately the problem seems not to be solved. Please have a look at the image. If I add then the -master_clk sync_clk_clock I once again get the timing violations.

2018-12-17_09h29_07_err.png

I just tried out the tipp you wrote here: https://forums.xilinx.com/t5/Timing-Analysis/BUFGMUX-constraint/td-p/736117

I totally understand what you explained in that post and in my post above and I try to repeat here:

Setting the false paths on the input clocks is only valid if they are really not used for clocking other resources which might have CDC issues because with the physically_exclusive setting I disable all CDC timing checks on these clocks. Because of that I really like your idea with the "create_generated_clocks" because with these constraints I can be sure that just the path after the BUFGCTRL is constrainted with that constraint and CDC is not disabled globally for these clocks.

That said I had a look in the UG835 (created_generated_clock) but I wasn't able to get the correct syntax. Perhaps you could help once again. :)

 

Sorry for setting the post to solved.

Kind regards

Sebastian

0 Kudos
Historian
Historian
950 Views
Registered: ‎01-23-2009

Re: Timing problems when adding second clock

Jump to solution

Yes, you are right - I (once again) forgot about the requirement to have the -master_clock option with the -add (although I never understood why this is necessary). So add the -master_clock back in. I said it was unnecessary in my previous message (which was incorrect), but I never said it was wrong.

If, after adding the -master_clock, you are still failing timing, then the problem is something else - the constraints on the clock MUX are correct.

Post the detailed path report of the failing path.

Avrum

0 Kudos
Explorer
Explorer
924 Views
Registered: ‎04-01-2016

Re: Timing problems when adding second clock

Jump to solution

 

Hi @avrumw

I noticed that the problem is not solved by the timing constraints. But I think I know a little bit more now. I see the following timing report with multiple_clocks:

 2019-01-05_13h29_18.png

 

I had a look at several paths and all the paths result from that clock multiplexer. I post one example:

2019-01-05_13h30_28_t5.png

 

So it seems that the timing constraints are not working? Because I didn't know how to proceed I had a look in UG906, but there I only found this:

2019-01-05_13h35_43_t3.png

 

I hope that anybody can help. One again my 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_clk_ctrl_i/BUFGMUX_CTRL_inst/I0] [get_pins fpga_asic_dummy_inst0/rcm_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_clk_ctrl_i/BUFGMUX_CTRL_inst/I1] [get_pins fpga_asic_dummy_inst0/rcm_clk_ctrl_i/BUFGMUX_CTRL_inst/O]
set_clock_groups -physically_exclusive -group fosc_clk_mux -group sync_clk_mux

Kind regards

Sebastian

 

0 Kudos