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: 
Visitor xsilverx
Visitor
4,523 Views
Registered: ‎11-19-2012

Hotswitching between 2 CLKs.

Jump to solution

Hello! I have xc7k160tffg676-2 and 2 clock sources:
1) Main - 25 MHz
2) Optional - 128 MHz
If optional clock is active, I should use it, but if it isn't, I should switch on Main.


There is my clk_gen core scheme which I use as IP in block design.

 

There are constraints for my clk_gen core.
create_clock -period 40.000 -name clk_25 [get_ports clk_25]
create_clock -period 7.812 -name clk_128_p [get_ports clk_128_p]

 

 

1) Route Design message


[Timing 38-282] The design failed to meet the timing requirements. Please see the timing summary report for details on the timi
ng violations.

 

Implementation Clock Summary
Name Waveform Period (ns) Frequency (MHz)
clk_128 {0.000 3.906} 7,812 128,008
CLKFBOUT_1 {0.000 3.906} 7,812 128,008
pll_128_clk {0.000 3.906} 7,812 128,008
clk_25 {0.000 20.000} 40,000 25,000
CLKFBOUT {0.000 20.000} 40,000 25,000
mmcm_25_128 {0.000 3.906} 7,812 128,000

 

So, I have problems with Inter-Clock Paths (mmcm_25_128 to pll_128_clk) requirements :
Setup requirement 7.812
Hold requirement 0.000

 

How can I write constraints to get correct timing analysis for "BUFGMUX_CTRL_inst/O" clocked logic?

What can I do with period discretizaton error (7.812 ns = 128.008MHz)?

 

 

2) Write Bitstream message


[DRC 23-20] Rule violation (REQP-1706) Clock output performance paths - Unsupported PLLE2_ADV connectivity. The signal mb_core_i/clk_gen_0/U0/pll_128/CLKFBOUT on the mb_core_i/clk_gen_0/U0/pll_128/clk_128_pll/CLKFBOUT pin of mb_core_i/clk_gen_0/U0/pll_128/clk_128_pll does not use dedicated connectivity. Routing from this pin to other than a BUFG or BUFH buffer type uses a non-performance path. Use CLOCK_DEDICATED_ROUTE constraint on the net. Note: using the CLOCK_DEDICATED_ROUTE option may not be sufficient to achieve this routing.

 

Implementation plasing results:
mmcm_25
Site : MMCME2_ADV_X0Y3
Tile : CMT_TOP_R_LOWER_B_X8Y165
clk_128_pll
Site : PLLE2_ADV_X0Y4
Tile : CMT_TOP_R_UPPER_T_X8Y252
BUFGMUX_CTRL_inst
Site : BUFGCTRL_X0Y16
Tile : CLK_BUFG_TOP_R_X95Y157

 

Why BUFGMUX_CTRL primitive doesn't satisfy this requirement?

clker.png
0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
8,594 Views
Registered: ‎01-23-2009

Re: Hotswitching between 2 CLKs.

Jump to solution

So a couple of points...

 

1) Using of BUFR for feedback paths are allowed. So I just want to optimize using of clocking resources. May be it's silly)

 

Legal, maybe, recommended, no...

 

What are you trying to accomplish with the feedback? Are you trying to deskew the input clock (so that the phase of the clock at the internal flip-flops matches the clock at the input of the FPGA - i.e. to capture an input interface or generate an output interface with known timing), or is the phase of the clock irrelevant and you just need the correct frequencies.

 

If you are trying to deskew a clock, then you must use the same clock resource on the feedback path as you use on the clocks being fed out of the MMCM. In your case you use BUFGs for the generated clocks (including a BUFGMUX), so you would need to use a BUFG on the feedback clock to match the phase. For systems like this you should always use the same clock resources - either all BUFGs (or variants) or all BUFHs.

 

If you mix and match buffers, then the phase of the output clock is unknown with respect to the input clock. In this case, you would be better off not using any buffer on the feedback, and simply connect CLKFBOUT directly to CLKFBIN (which is legal).

 

3) Can I eliminate errors in timing analysis by create virtual clock "BUFGMUX_CTRL_inst/O" with 8.712 period?

 

Don't do this. There is only one place where a primary clock (create_clock) should be used inside an FPGA, which is on the TXOUTCLK or RXOUTCLK of a high speed serial I/O block (GTP/GTX/GTH/...). Furthermore, you can't put a "virtual" clock anywhere, since, by definition a "virtual" clock is a clock that is not connected to your design.

 

In Vivado, a net/pin/port can carry more than one clock - in general this can be a very powerful tool. So, by default, when the two clocks reach the BUFGMUX, the output of the BUFGMUX carries both clocks, and the tool analyzes all paths as if they are on both clocks. Of course, in this case, this is not what you want.

 

The standard way of dealing with this is to create physically exclusive clock groups for the two clocks. BUT first, you must be certain that the two output clocks of the MMCM don't go anywhere other than the inputs of the BUFGMUX. If so, then you can use this command

 

set_clock_groups -physically_exclusive -group [get_clocks -of_objects [get_pins BUFGMUX_CTRL_inst/I0]] -group  [get_clocks -of_objects [get_pins BUFGMUX_CTRL_inst/I1]]

 

This declares all paths between these two clocks as false.

 

Avrum

4 Replies
Moderator
Moderator
4,510 Views
Registered: ‎01-16-2013

Re: Hotswitching between 2 CLKs.

Jump to solution

Hi,

 

So I have seen the schematic and the details. Below are my suggestions.

1) The feedback path of PLL and MMCM you are using BUFR, but it's better if you use BUFG.

2) I hope the port's which you connected the clock directly as output are not going directly outside the FPGA and you are using those clock for other IP's in your block design. If you want to forward the clock you should not connect it directly to the output, best way is to use ODDR technique to use for clock forwarding.

3) Regarding the constraints associated with BUFGMUX the input clocks can't be available at same time at output but tool will not understand this hardware behaviour unless you specified exception constraints.

You have to specify set_clock_group exclusive clock constraints. From the schematic looks like it's physically exclusive constraints will work but as I don't have knowledge of bigger schematic it's better if you can refer UG 903 and decide whether physical exclusive will work or logical exclusive work.

 

For your ease refer ug 903: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_2/ug903-vivado-using-constraints.pdf (clock group section)

 

Thanks,
Yash

0 Kudos
Visitor xsilverx
Visitor
4,492 Views
Registered: ‎11-19-2012

Re: Hotswitching between 2 CLKs.

Jump to solution

1) Using of BUFR for feedback paths are allowed. So I just want to optimize using of clocking resources. May be it's silly)

2) I use this IP core as clock generator for my block design. BUFGMUX drives global clock tree for all design elements which placed at the same Kintex 7 FPGA. This schematic is just out-of-context synthesis result.

3) Can I eliminate errors in timing analysis by create virtual clock "BUFGMUX_CTRL_inst/O" with 8.712 period?

Why does VIvado perform cross-clock analysis for clk128_pll/CLKOUT0 and mmcm_25/CLKOUT0? There are not 2 clock domains, actually! This two clocks are only the switching sources for "BUFGMUX_CTRL_inst/O", which is drive the real logic. BUFGMUX switching is glitch-free. So, there is only PERIOD constraint for this clock domain, isn't it?

Thanks for feedback!

0 Kudos
Historian
Historian
8,595 Views
Registered: ‎01-23-2009

Re: Hotswitching between 2 CLKs.

Jump to solution

So a couple of points...

 

1) Using of BUFR for feedback paths are allowed. So I just want to optimize using of clocking resources. May be it's silly)

 

Legal, maybe, recommended, no...

 

What are you trying to accomplish with the feedback? Are you trying to deskew the input clock (so that the phase of the clock at the internal flip-flops matches the clock at the input of the FPGA - i.e. to capture an input interface or generate an output interface with known timing), or is the phase of the clock irrelevant and you just need the correct frequencies.

 

If you are trying to deskew a clock, then you must use the same clock resource on the feedback path as you use on the clocks being fed out of the MMCM. In your case you use BUFGs for the generated clocks (including a BUFGMUX), so you would need to use a BUFG on the feedback clock to match the phase. For systems like this you should always use the same clock resources - either all BUFGs (or variants) or all BUFHs.

 

If you mix and match buffers, then the phase of the output clock is unknown with respect to the input clock. In this case, you would be better off not using any buffer on the feedback, and simply connect CLKFBOUT directly to CLKFBIN (which is legal).

 

3) Can I eliminate errors in timing analysis by create virtual clock "BUFGMUX_CTRL_inst/O" with 8.712 period?

 

Don't do this. There is only one place where a primary clock (create_clock) should be used inside an FPGA, which is on the TXOUTCLK or RXOUTCLK of a high speed serial I/O block (GTP/GTX/GTH/...). Furthermore, you can't put a "virtual" clock anywhere, since, by definition a "virtual" clock is a clock that is not connected to your design.

 

In Vivado, a net/pin/port can carry more than one clock - in general this can be a very powerful tool. So, by default, when the two clocks reach the BUFGMUX, the output of the BUFGMUX carries both clocks, and the tool analyzes all paths as if they are on both clocks. Of course, in this case, this is not what you want.

 

The standard way of dealing with this is to create physically exclusive clock groups for the two clocks. BUT first, you must be certain that the two output clocks of the MMCM don't go anywhere other than the inputs of the BUFGMUX. If so, then you can use this command

 

set_clock_groups -physically_exclusive -group [get_clocks -of_objects [get_pins BUFGMUX_CTRL_inst/I0]] -group  [get_clocks -of_objects [get_pins BUFGMUX_CTRL_inst/I1]]

 

This declares all paths between these two clocks as false.

 

Avrum

Highlighted
Visitor xsilverx
Visitor
4,461 Views
Registered: ‎11-19-2012

Re: Hotswitching between 2 CLKs.

Jump to solution

1) I want to desque a clock. Placing BUFG on feedback paths eliminates problem with deskewing and unsupported PLLE2_ADV connectivity.
3) set_clock_groups -physically_exclusive -group [get_clocks -of_objects [get_pins BUFGMUX_CTRL_inst/I0]] -group  [get_clocks -of_objects [get_pins BUFGMUX_CTRL_inst/I1]]

Using this constraint resolves problem with redundant timing analysis.

 

Thank you for operative help!

0 Kudos