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
4,507 Views
Registered: ‎05-14-2015

set_clock_groups

Jump to solution

I got a critical warning as below. Don't know why. "clk_out2_clk_wiz_300IN_1" is a clock generated by PLL.

 

 

[Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group [get_clocks clk_out2_clk_wiz_300IN_1]'. ["C:/work/LaTrappe/SVN/UHDSDI/uhdsdi_10gbe/xdc/timing.xdc":32]

 

Below is the part in my .xdc file where this warning is refering.

 

set_clock_groups -asynchronous -group [get_clocks clk_125MHz] -group [get_clocks clk_out2_clk_wiz_300IN_1]

set_clock_groups -asynchronous -group [get_clocks rxoutclk_out[0]] \
                               -group [get_clocks txoutclk_out[0]] \
                               -group [get_clocks clk_out2_clk_wiz_300IN_1]

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
5,819 Views
Registered: ‎01-23-2009

Re: set_clock_groups

Jump to solution

The attached is the log file for synthesis. I didn't find where is the first pass of reading and where is the second pass of reading. Can you help to have a look? 

 

The flow is different in project mode vs. non-project mode.

 

In non-project mode, both passes of reading the XDC file are part of the "synth_design" command; one before filling in the black boxes, and one after.

 

In project mode, only the first pass is done as part of the synth_1 run. During this run, the IP blocks are black boxes. It appears that the cell "i_systempll" is a black box, and hence the generated clocks inside it do not yet exist (I will come back to this later).

 

The second pass is done by (both of) the opening of the synthesized design, and/or the launching the implementation run. In these processes the original XDC files are read in again, but this time the black boxes have been filled in, and hence the constraint passes.

 

Now, as to the first pass. Even though the i_systempll is a black box, this does not mean the clock nets coming out of it do not have constraints. The synthesis process reads the constraint file clk_wiz_300IN_in_context.xdc associated with the black box. This file defines clocks of the appropriate frequencies and phases on the outputs of the black box cell. However, there is nothing that guarantees that the name of these clocks is the same when they are read from the "in_context" XDC file, and when they are automatically generated by the tool (once the black box is filled in).

 

To protect yourself against that, don't use the name of the clock in your set_clock_groups command. Rather than use

 

[get_clocks clk_out2_clk_wiz_300IN_1]

 

use

 

[get_clocks -of_objects [get_pins <output_pin_of_i_syspll]]

 

This command will return the clock regardless of whether it is the "in_context" clock or the real clock later on.

 

If "set_clock_groups" is dangerous for CDCC, what's the alternative to improve this? 

 

The set_clock_groups command is dangerous because

  - It is the highest priority constraint, so disables any other constraint on a path that is also covered by this constraint

  - It is a blanket "clock to clock" constraint, and hence covers all paths between the two clocks (in both directions)

 

These two things together make this dangerous - it overrides all other constraints between these clocks.

 

If you need a set_false_path on the input of a CDCC, then use the set_false_path on that path only - not between clocks.

 

Furthermore, more often than not, most CDCCs need a set_max_delay -datapath_only for correct operation. This command still has the effect of overriding the normal synchronous constraint on a path (which is incorrect for a CDC path), but does not leave the path completely unconstrained.

 

You can take a look at this topic on constraining CDCCs (including the posts referenced therein), as well as this one on the clock interaction report (including the comments).

 

Avrum

Tags (1)
8 Replies
Scholar jmcclusk
Scholar
4,488 Views
Registered: ‎02-24-2014

Re: set_clock_groups

Jump to solution

Try loading the synthesized design in Vivado, and run [get_clocks] in the TCL console to see the list of known clocks..   It's likely that this particular clock is either not present at all, or has a slightly different name.

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Explorer
Explorer
4,471 Views
Registered: ‎05-14-2015

Re: set_clock_groups

Jump to solution

@jmcclusk,

I did "get_clocks". The below is the output:

clk clk_125MHz sfp_RefClk_p0 sfp_RefClk_p1 gth_qpll0_clk_out gth_qpll0_refclk_out gth_qpll1_clk_out gth_qpll1_refclk_out 
clkfbout_clk_wiz_300IN_1 clk_out1_clk_wiz_300IN_1 clk_out2_clk_wiz_300IN_1 clk_out3_clk_wiz_300IN_1 
rxoutclk_out[0] rxoutclkpcs_out[0] txoutclk_out[0] txoutclkpcs_out[0] nidru_clk0

The clock name in this list is exactly the same as what i have listed in .xdc file. Really don't know why this critical warning is still popping up. 

0 Kudos
Highlighted
Moderator
Moderator
4,446 Views
Registered: ‎11-04-2010

Re: set_clock_groups

Jump to solution
Hi, @softwind555 ,
The critical warning during synthesis is expected.
When compiling the source files and XDC files, the auto-generated clock for MMCM/PLL is still known for Vivado. So the CW occurs.
To verify the set_clock_groups constraint, you can open_synthesized design and report timing between 2 clock domains:
report_timing -group [get_clocks clk_125MHz] -group [get_clocks clk_out2_clk_wiz_300IN_1] -name test
The requirement of the reported path should be infinite, it means the set_clock_groups constraint takes effect.

To avoid the this CW during synthesis, you can refer the MMCM's output clock with the output pin of MMCM, instead to using the auto-generated clock's name directly.
For example old: get_clocks clk_out2_clk_wiz_300IN_1
new: get_clocks -of [get_pins XX_MMCM/CLKOUT2]
-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Historian
Historian
4,440 Views
Registered: ‎01-23-2009

Re: set_clock_groups

Jump to solution

When compiling the source files and XDC files, the auto-generated clock for MMCM/PLL is still known for Vivado

 

(I presume you meant "unknown"). And this is not completely correct.

 

The question is "where is this MMCM" - specifically is it in an IP block or not.

 

An MMCM instantiated in RTL (or even used from the clocking wizard, which is an "odd" IP that does not get synthesized out-of-context), will have the auto-generated clocks created during synthesis, so the auto-generated clocks are available for use in the XDC file during synthesis and implementation.

 

However, an MMCM instantiated in an IP block will not. Most IP are synthesized out-of-context (OOC) - they are synthesized separately to create a netlist. This netlist is then used during the implementation process.

 

When the top level of the design is synthesized, the OOC IPs are not part of the synthesis run - these instances are "black boxes". As a result, the MMCMs don't exist in the synthesis runs, so neither do their automatically generated clocks.

 

However, it is important to notice that the XDC files are read twice during synthesis. On the first pass, the IP blocks are black boxes, and hence you can get critical warnings. The second XDC pass is done at the end of synthesis - after the IP netlists are read in to fill in the "black boxes". During this second pass, the constraints will go through normally.

 

This is usually the cause of critical warnings about "clock not found" which appear to contradict the synthesized design (where the clock does exist).

 

The net result is that your design is improperly constrained for synthesis, but is properly constrained for implementation. If

  - you can confirm that this is the case

     - you can look through the synthesis log file to see the two readings of the XDC file that contains the reference to the clock, and ensure that the critical warning only occurs during the first one and

  - the design meets timing after implementation

 

then you can ignore the critical warning.

 

If you want it to go away, you will need to write a separate constraint file that does not use the clock in question, and use that for synthesis (remove the USED_IN_IMPLEMENTATION flag from that one) and then use the real one only in implementation (remove the USED_IN_SYNTHESIS flag from that one).

 

But, I need to give my standard warning. The "set_clock_groups" command is a VERY DANGEROUS command. It disables all timing checks on any paths between the two domains. If paths exist between clock domains, then they need clock domain crossing circuits (CDCCs) and the vast majority of CDCCs need constraints. In fact, some IPs with CDCCs (including some clock crossing FIFOs) already have proper constraints. Using the set_clock_groups overrides any constraints on these paths - thus changing properly constrained CDCCs to unconstrained CDCCs, which can cause system failures...

 

Avrum

Explorer
Explorer
4,411 Views
Registered: ‎05-14-2015

Re: set_clock_groups

Jump to solution

@avrumw  thank you!

The attached is the log file for synthesis. I didn't find where is the first pass of reading and where is the second pass of reading. Can you help to have a look? 

 

If "set_clock_groups" is dangerous for CDCC, what's the alternative to improve this? 

 

@hongh, Thank you!

How to find out the exact name for"XX_MMCM" inside "get_clocks -of [get_pins XX_MMCM/CLKOUT2]"? 

The attachment includes the netlist screenshot for the instance of clock wizard in my design. Can you help to have a look what would be a proper way to constraint it without this critical warning? 

0 Kudos
Moderator
Moderator
4,397 Views
Registered: ‎11-04-2010

Re: set_clock_groups

Jump to solution
Hi, @softwind555 ,
After opening the synthesized design, type the below command in TCL CONSOLE:
show_objects -name find_2 [get_cells -hierarchical -filter { PRIMITIVE_TYPE =~ CLOCK.PLL.* } ]
select the target MMCM/PLL, rihgt click -> Schematic
Select the output pin of MMCM/PLL in Schematic and find the pin name in "Cell pin properties" Window
-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Historian
Historian
5,820 Views
Registered: ‎01-23-2009

Re: set_clock_groups

Jump to solution

The attached is the log file for synthesis. I didn't find where is the first pass of reading and where is the second pass of reading. Can you help to have a look? 

 

The flow is different in project mode vs. non-project mode.

 

In non-project mode, both passes of reading the XDC file are part of the "synth_design" command; one before filling in the black boxes, and one after.

 

In project mode, only the first pass is done as part of the synth_1 run. During this run, the IP blocks are black boxes. It appears that the cell "i_systempll" is a black box, and hence the generated clocks inside it do not yet exist (I will come back to this later).

 

The second pass is done by (both of) the opening of the synthesized design, and/or the launching the implementation run. In these processes the original XDC files are read in again, but this time the black boxes have been filled in, and hence the constraint passes.

 

Now, as to the first pass. Even though the i_systempll is a black box, this does not mean the clock nets coming out of it do not have constraints. The synthesis process reads the constraint file clk_wiz_300IN_in_context.xdc associated with the black box. This file defines clocks of the appropriate frequencies and phases on the outputs of the black box cell. However, there is nothing that guarantees that the name of these clocks is the same when they are read from the "in_context" XDC file, and when they are automatically generated by the tool (once the black box is filled in).

 

To protect yourself against that, don't use the name of the clock in your set_clock_groups command. Rather than use

 

[get_clocks clk_out2_clk_wiz_300IN_1]

 

use

 

[get_clocks -of_objects [get_pins <output_pin_of_i_syspll]]

 

This command will return the clock regardless of whether it is the "in_context" clock or the real clock later on.

 

If "set_clock_groups" is dangerous for CDCC, what's the alternative to improve this? 

 

The set_clock_groups command is dangerous because

  - It is the highest priority constraint, so disables any other constraint on a path that is also covered by this constraint

  - It is a blanket "clock to clock" constraint, and hence covers all paths between the two clocks (in both directions)

 

These two things together make this dangerous - it overrides all other constraints between these clocks.

 

If you need a set_false_path on the input of a CDCC, then use the set_false_path on that path only - not between clocks.

 

Furthermore, more often than not, most CDCCs need a set_max_delay -datapath_only for correct operation. This command still has the effect of overriding the normal synchronous constraint on a path (which is incorrect for a CDC path), but does not leave the path completely unconstrained.

 

You can take a look at this topic on constraining CDCCs (including the posts referenced therein), as well as this one on the clock interaction report (including the comments).

 

Avrum

Tags (1)
Explorer
Explorer
4,298 Views
Registered: ‎05-14-2015

Re: set_clock_groups

Jump to solution

@avrumw,  Thank you! 

Sorry to interrupt you with more questions.

I have went through the topic about CDC constraint you have written in this forum. 

I would like to give some of my understanding as below and hope you can help to check if it's correct or not.  

 

For example,  a design is like below:

1.  It contains CLK_A, CLK_B, CLK_C and CLK_D

2.  A high speed video data stream is crossing CLK_A and CLK_B domain.  The CDC circuit between CLK_A and CLK_B is using Xilinx's XPM module "XPM_MEMORY_SDPRAM". It's a simple dual port RAM. This RAM is used to form a FIFO to act as CDC circuit from CLK_A to CLK_B. 

3. Between CLK_A and CLK_C, there is no high speed video data stream. There is only some low speed, low transition frequency  signals which are transferred between these 2 clock domains.  2 back-to-back Flip-Flops have been used as CDC circuit to transfer these data between these 2 clock domains. 

4. Between CLK_A and CLK_D, there are both high speed video stream and low-speed and low-transition-frequency signals. "XPM_MEMORY_SDPRAM" has been used for video stream from CLK_A to CLK_D.  2 back-to-back Flip-Flops have been used as CDC circuit for  low-speed and low-transition-frequency signals.

5.  CLK_B, CLK_C and CLK_D are completely unrelated. There are no paths in-between any of pairs of them. 

5.  CLK_A=150MHZ.  CLK_B=300MHZ, CLK_C=100MHZ; CLK_D=297MHZ;

 

In order to constrain them properly, the following constraints will be implemented: 

set period_CLK_B [expr ([get_property PERIOD [get_clocks CLK_B]]-0.1)] 
set period_CLK_D [expr ([get_property PERIOD [get_clocks CLK_D]]-0.1)]

;# CDC between CLK_A and CLK_B
set_max_delay $period_CLK_B -datapath_only -from [get_clocks CLK_A] -to [get_clocks CLK_B]

;# CDC between CLK_A and CLK_C
set_clock_groups -asynchronous -group [get_clocks CLK_A] -group [get_clocks CLK_C]

;# CDC between CLK_A and CLK_D
set_max_delay $period_CLK_D -datapath_only -from [get_clocks CLK_A] -to [get_clocks CLK_D]
set_max_delay $period_CLK_D -datapath_only -from [get_clocks CLK_D] -to [get_clocks CLK_A]

Do you think these constraints are correct? Is it over-constrainted because I always use the period of the fastest clock as the value of max_delay? 

0 Kudos