Hold time : clock domains clk1x and clk1x_1

[alectronic]

Hello ,

I'm not an expert in the subject of fixing hold violations .

Could some body explain me what does o_CLK1x to o_CLK1x_1 mean in the photo below ?

In the design I have only  o_CLK1x .It is one of a PLL's output  .

What is o_CLK1x_1 and why there are hold violations between these two clock's domains ?

Thank in advance

Alex

[graces · Accepted solution]

You may run "report_clocks" to see how these two clocks are defined.

[watari]

Hi @alectronic

I guess, it defines o_CLK1x_1 on BUFGMUX/O.

If my understanding is correct, this timing violation come from OCV.

Would you make sure report_clock and hold timing violation path ?

Best regards,

[markg@prosensing.com]

@alectronic

When you use the BUFGMUX, you usually need to write certain XDC constraints. When these constraints are missing, you can get timing analysis problems like the ones you are seeing.

Specifically, I believe that Vivado has assigned the names o_CLK1x and o_CLK1x_1 to the clock inputs, (I0 and I1), of the BUFGMUX. In ways that are difficult to explain, timing analysis assumes interaction between these clocks on the blue-highlighted path you have shown. At this blue-highlighted timing path, there is of course no interaction between o_CLK1x and o_CLK1x_1 because only one of these clocks gets through the BUFGMUX at a time. If there is no interaction (ie. clock crossings) between o_CLK1x and o_CLK1x_1 anywhere in your design, then using the following XDC constraint should solve many of the timing analysis problems you are seeing.

set_clock_groups -logically_exclusive -group [get_clocks o_CLK1x] -group [get_clocks o_CLK1x_1]

For more information about set_clock-groups - logically_exclusive, see “Overlapping Clocks Driven by a Clock Multiplexer” on about pg165 of UG949 and “Logically Exclusive Clock Groups with no Interaction” on about pg43 of UG903.

However, there are other issues with your clock routing, which is:
     PLL > LUT6 > BUFG > BUFGMUX

Please tell us what you are doing with the LUT6 and why you need the BUFGMUX.

Cheers,
Mark

[alectronic]

Hi markg@prosensing.com

Thank you for your clear reply .

All is clear for me regarding the report_clocks  and contraints I have to apply to CLK1x and CLK1x_1 .

I think there is no issu .

This is my VHDL :

PLL_SP_inst : PLL_SP
PORT MAP(
i_CLK => PCLK_IN,
i_CLK_200M => i_CLK_200M,
i_RST => PLL_SP_RST,
o_CLK1x => PLL_SP_CLK1x,
o_CLK1x_dephase => PLL_SP_CLK1x_dephase,
o_CLK2x => PLL_SP_CLK2x,
o_CLKdiv2 => PLL_SP_CLKdiv2,
o_PLL_Locked => PLL_SP_LOCKED
);

o_PLL_SP_LOCKED <= PLL_SP_LOCKED ;

PCLK_INT <= PLL_SP_CLKdiv2 WHEN SEL_PCLK_INT = "0010000" else --SDI_3G_levelB uniquement
PLL_SP_CLK1x ;

PLL_SP_CLKdiv2_int <= PLL_SP_CLKdiv2 WHEN SEL_PCLK_INT = "0100000" else --SDI_3G_levelA uniquement
'0' ;

BUFG_inst1 : BUFG
PORT MAP (
O => o_PCLK_INT, -- 1-bit output: Clock output
I => PCLK_INT -- 1-bit input: Clock input
);

BUFG_inst2 : BUFG
PORT MAP (
O => o_PLL_SP_CLK1x_dephase, -- 1-bit output: Clock output
I => PLL_SP_CLK1x_dephase -- 1-bit input: Clock input
);

BUFG_inst3 : BUFG
PORT MAP (
O => o_PCLKdiv2_INT, -- 1-bit output: Clock output
I => PLL_SP_CLKdiv2_int -- 1-bit input: Clock input
);

BUFG_inst4 : BUFG
PORT MAP (
O => o_PCLKdiv2_INT, -- 1-bit output: Clock output
I => PLL_SP_CLKdiv2_int -- 1-bit input: Clock input
);

Best regards

Alex

[alectronic]

The BUFGMUX is needed because the input Clk frequency of the TOP_OUTPUT_inst should always be 74.25MHz .
The Input Clk signal of the design could be 74.25MHz or 148.5MHz .
So I need to switch between these to Clks

[avrumw]

OK - before we get to the constraints, lets look at the clock structure. We have a couple of problems here...

As markg@prosensing.com, you should not (pretty much ever) have a LUT in your clock path. There are some problems with your code

• BUFG_inst3 and _inst4 are identical instantiations in your code, which would result in a multidriver net
• You have one piece of combinatorial code that describes a clock MUX - it even appears that the tools inferred a BUFGMUX for it
• You have another piece of code that describes a clock gate - this is what seems to be making the LUT

You shouldn't do (pretty much any of) this.

If you need a clock MUX instantiate a BUFGMUX. If you need a clock gate, instantiate a BUFGCE - clocking logic should not be inferred.

Furthermore, you should not be cascading global clock buffers. Both the BUFG and BUFGMUX are clock buffer and you have two BUFGs feeding the input to the BUFGMUX. This introduces skew between the unMUXed and MUXed clocks. In general, all clock buffers should be in parallel (i.e. the BUFGMUX inputs should be fed directly from the PLL with no BUFGs between them.

Next we need to understand what you are planning to do with all these clocks. Do you expect any of them to be synchronous - i.e. are there paths between one clock domain and another. If so, then these need to be planned very carefully. Two outputs of the same PLL going through exactly one buffer (a BUFG, a BUFGMUX a BUFGCE) can be treated synchronously if:

• The ratios between the clocks are not unreasonable
• The clocks are placed in the same CLOCK_DELAY_GROUP (see this post on the CLOCK_DELAY_GROUP - this applies to UltraScale/UltraScale+ only)

Next, if we have a clock multiplexer, then we need to be careful. If the two input clocks to the MUX ONLY go through the MUX, then you can declare the two input clocks as separate clock groups (as markg@prosensing.com). However, if the two clocks go elsewhere (i.e. through other BUFGs) and there is the potential of paths between the un-muxed paths, then declaring them as different groups is not safe (or correct). The process for constraining them is more complex.

Finally, back to your original question. You have two clocks whose names differ by a _1. In general this is because you have a problem with your constraints describing the input to the PLL. If you end up with two "create_clock" commands on the port upstream from the input of the PLL (with the second of the two having the -add flag) then there will be two clocks on the CLKIN input. The PLL will generate an automatically generated clock for each output based on each input clock - so since you have two clocks on the input clock, you will have two clocks on each output clock. These will be named with the name from the instantiation/clock wizard for the first one, and the same name with a _1 for the second one. Usually these occur due to the clocking wizard, which puts a create_clock on the input of the PLL (based on the frequency you specified when you created the PLL), in conjunction with a second one in your top level XDC.

Avrum

[alectronic]

hello @avrumw ,

Many thanks for your explanations .

I know that one of the priority of a design is the Clock paths an the clock paths of our designs are always complex .

I will do the modifications of this design and I will take care for the nexts .

I will do not hesitate to post a futur message if I will meet  new issus regarding clock path .

Best regards

Alex