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!
11-28-2018 07:16 AM
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
11-28-2018 10:03 PM
You may run "report_clocks" to see how these two clocks are defined.
11-28-2018 10:03 PM
You may run "report_clocks" to see how these two clocks are defined.
11-28-2018 10:20 PM
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,
11-29-2018 05:39 AM - edited 11-29-2018 08:05 AM
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
11-29-2018 06:07 AM
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
11-29-2018 08:52 AM
11-29-2018 08:58 AM
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
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:
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
11-30-2018 05:53 AM
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