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
988 Views
Registered: ‎07-03-2014

[Vivado 2017.4] Vivado reports source and destination clocks as different, but both are the same clock

Jump to solution

Hi,

 

After implementing my design, I get this weird timing report path:

 

 

Path 737	-4,65	4	32	Control/Control_System_i/microblaze_0_axi_mem/s04_mmu/inst/decerr_slave_inst/gen_axi.gen_read.read_cs_reg[0]/C	Control/Control_System_i/AXI_TS_Front_End_1/U0/Packet_Synchronizer/TS_RAM_Buffer/Inst_TS_AXI_FIFO_Interface1/U0/GEN_MM2S_FULL.I_MM2S_FULL_WRAPPER/I_RD_DATA_CNTL/sig_next_strt_strb_reg_reg[0]/R	7,46	0,61	6,85	0,37	CLK_108MHz_CLKDLL_Synth	axi_clk	

 

Path begins inside microblaze core and ends inside my own IP core. Both cores are included in a BD and both cores are clocked by the same clock, however, Vivado considers both clocks as different: source clock is named as "CLK_108MHz_CLKDLL_Synth" and destination clock is "axi_clk".

Taking a deep look at path report, both clocks are generated in the same DCM at the same output pin (as expected, since both are the same clocks):

 

SOURCE CLOCK:

    H17                                               0.000   129.629 r  CLK27MHZ_C (IN)
                         net (fo=0)                   0.000   129.629    DCM0/inst/CLK_IN
    H17                                                               r  DCM0/inst/clkin1_ibufg/I
    H17                  IBUF (Prop_ibuf_I_O)         1.724   131.353 r  DCM0/inst/clkin1_ibufg/O
                         net (fo=1, routed)           1.230   132.583    DCM0/inst/CLK_IN_CLKDLL_Synth
    MMCME2_ADV_X0Y3                                                   r  DCM0/inst/mmcm_adv_inst/CLKIN1
    MMCME2_ADV_X0Y3      MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT0)
                                                     -7.871   124.712 r  DCM0/inst/mmcm_adv_inst/CLKOUT0
                         net (fo=1, routed)           1.650   126.362    DCM0/inst/CLK_108MHz_CLKDLL_Synth
    BUFGCTRL_X0Y0                                                     r  DCM0/inst/clkout1_buf/I
    BUFGCTRL_X0Y0        BUFG (Prop_bufg_I_O)         0.120   126.482 r  DCM0/inst/clkout1_buf/O

 

DESTINATION CLOCK:

    H17                                               0.000     0.000 r  CLK27MHZ_C (IN)
                         net (fo=0)                   0.000     0.000    DCM0/inst/CLK_IN
    H17                                                               r  DCM0/inst/clkin1_ibufg/I
    H17                  IBUF (Prop_ibuf_I_O)         0.454     0.454 r  DCM0/inst/clkin1_ibufg/O
                         net (fo=1, routed)           0.503     0.957    DCM0/inst/CLK_IN_CLKDLL_Synth
    MMCME2_ADV_X0Y3                                                   r  DCM0/inst/mmcm_adv_inst/CLKIN1
    MMCME2_ADV_X0Y3      MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT0)
                                                     -2.619    -1.662 r  DCM0/inst/mmcm_adv_inst/CLKOUT0
                         net (fo=1, routed)           0.574    -1.088    DCM0/inst/CLK_108MHz_CLKDLL_Synth
    BUFGCTRL_X0Y0                                                     r  DCM0/inst/clkout1_buf/I
    BUFGCTRL_X0Y0        BUFG (Prop_bufg_I_O)         0.026    -1.062 r  DCM0/inst/clkout1_buf/O

How can I force Vivado to treat both clocks as the same? Timing would be successful if Vivado didn't consider source and destination clocks as different.

 

Regards.

0 Kudos
1 Solution

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

Re: [Vivado 2017.4] Vivado reports source and destination clocks as different, but both are the same clock

Jump to solution

I am not certain you are using your terms correctly...

 

OOC (out of context) is a particular flow that is used for synthesizing (and even implementing) modules on their own - without a top level design around them. IP modules are (by default) synthesized OOC.

 

When synthesizing OOC, there are some constraints that are used only on the OOC run - these are usually clearly named with the *_ooc.xdc name; and even if not, can be identified by the "USED_IN" property of the XDC file containing "out_of_context"

 

Regardless of whether a module is synthesized OOC or not, a module can have "scoped constraints". These constraints are applied to the module whenever it is used; this would be both when synthesized OOC as well as when integrated into a design - these constraints would be applied to all instances of the module. These can be identified by the property "SCOPED_TO_REF" being set to the name of the module (without the "USED_ON" having "out_of_context").

 

The clock wizards (notoriously) include constraints on their primary clocks - the values are determined by the numbers used in when you configure the clocks through the wizard  - you tell it the frequency of the input clock and it uses this as the constraint. This could well be the source of one of the clocks. The other presumably comes from your top level constraints. Normally this is not a problem as long as they are both correct values - one will override the other. However, given that you saw paths with different start and end clocks, you probably have the "-add" option specified in your constraint file. This is not a "normal" thing to do... With the -add option, both clocks remain on the network, which can cause all kinds of problems.

 

So, in general, never use the "-add" option (unless you really know why you need to use it - there are very specific cases where it is necessary, but they are rate). You can then decide if you want to use the constraints from the IP only (and remove yours), or let yours override the one in the IP (which generates a warning), or use yours and disable the IP XDC file.

 

Avrum

0 Kudos
5 Replies
Observer tl_rtclancy
Observer
968 Views
Registered: ‎12-13-2017

Re: [Vivado 2017.4] Vivado reports source and destination clocks as different, but both are the same clock

Jump to solution

It looks like the reset pin is involved on the second flop. You may want to pull up the schematic for the path as it may be different than what you think it is or perhaps you have done this already. Just a thought.

 

Best regards,

Bob

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

Re: [Vivado 2017.4] Vivado reports source and destination clocks as different, but both are the same clock

Jump to solution

It looks like you might have two primary clocks applied to the same clock tree - with the second one having the -add option. This is most likely an error.

 

Take a look at the "report_clocks" command - this should show both.

 

You can also look at the constraints window (Window -> Timing Constraints) - the bottom of this window will show all the constraints that have been applied and what file the constraints come from...

 

Avrum

Explorer
Explorer
932 Views
Registered: ‎07-03-2014

Re: [Vivado 2017.4] Vivado reports source and destination clocks as different, but both are the same clock

Jump to solution

@avrumw

Thanks for your tip; I looked at Timing Constraints window and found out what was happening: destination clock was reported as part of "TS_Front_End" IP core and there was a "TS_Front_End_xdc" file where an invalid constraint was present:

 

create_clock -period 10.000 -name axi_clk -waveform {0.000 5.000} [get_ports axi_aclk]

However, this XDC file is not compiled as OOC, and is not included in the top project... How did this constraint apply on the top project? I thought the only constraints that propagated from IP core to top project were those included in OOC XDC files... Am I wrong?

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

Re: [Vivado 2017.4] Vivado reports source and destination clocks as different, but both are the same clock

Jump to solution

I am not certain you are using your terms correctly...

 

OOC (out of context) is a particular flow that is used for synthesizing (and even implementing) modules on their own - without a top level design around them. IP modules are (by default) synthesized OOC.

 

When synthesizing OOC, there are some constraints that are used only on the OOC run - these are usually clearly named with the *_ooc.xdc name; and even if not, can be identified by the "USED_IN" property of the XDC file containing "out_of_context"

 

Regardless of whether a module is synthesized OOC or not, a module can have "scoped constraints". These constraints are applied to the module whenever it is used; this would be both when synthesized OOC as well as when integrated into a design - these constraints would be applied to all instances of the module. These can be identified by the property "SCOPED_TO_REF" being set to the name of the module (without the "USED_ON" having "out_of_context").

 

The clock wizards (notoriously) include constraints on their primary clocks - the values are determined by the numbers used in when you configure the clocks through the wizard  - you tell it the frequency of the input clock and it uses this as the constraint. This could well be the source of one of the clocks. The other presumably comes from your top level constraints. Normally this is not a problem as long as they are both correct values - one will override the other. However, given that you saw paths with different start and end clocks, you probably have the "-add" option specified in your constraint file. This is not a "normal" thing to do... With the -add option, both clocks remain on the network, which can cause all kinds of problems.

 

So, in general, never use the "-add" option (unless you really know why you need to use it - there are very specific cases where it is necessary, but they are rate). You can then decide if you want to use the constraints from the IP only (and remove yours), or let yours override the one in the IP (which generates a warning), or use yours and disable the IP XDC file.

 

Avrum

0 Kudos
Explorer
Explorer
889 Views
Registered: ‎07-03-2014

Re: [Vivado 2017.4] Vivado reports source and destination clocks as different, but both are the same clock

Jump to solution

@avrumw wrote:

I am not certain you are using your terms correctly...

 

OOC (out of context) is a particular flow that is used for synthesizing (and even implementing) modules on their own - without a top level design around them. IP modules are (by default) synthesized OOC.

 

When synthesizing OOC, there are some constraints that are used only on the OOC run - these are usually clearly named with the *_ooc.xdc name; and even if not, can be identified by the "USED_IN" property of the XDC file containing "out_of_context"

 

Regardless of whether a module is synthesized OOC or not, a module can have "scoped constraints". These constraints are applied to the module whenever it is used; this would be both when synthesized OOC as well as when integrated into a design - these constraints would be applied to all instances of the module. These can be identified by the property "SCOPED_TO_REF" being set to the name of the module (without the "USED_ON" having "out_of_context").

 

Avrum


 

Thanks for the explanation; I thought it was just the other way round: I thought OOC constraints were applied to the module on its own and also the complete design where it is part of.

 

 


@avrumw wrote:
The clock wizards (notoriously) include constraints on their primary clocks - the values are determined by the numbers used in when you configure the clocks through the wizard  - you tell it the frequency of the input clock and it uses this as the constraint. This could well be the source of one of the clocks. The other presumably comes from your top level constraints. Normally this is not a problem as long as they are both correct values - one will override the other. However, given that you saw paths with different start and end clocks, you probably have the "-add" option specified in your constraint file. This is not a "normal" thing to do... With the -add option, both clocks remain on the network, which can cause all kinds of problems.

 

So, in general, never use the "-add" option (unless you really know why you need to use it - there are very specific cases where it is necessary, but they are rate). You can then decide if you want to use the constraints from the IP only (and remove yours), or let yours override the one in the IP (which generates a warning), or use yours and disable the IP XDC file.

 

Avrum


 

I never had heard of -add constraint until you talked about it a couple of days ago in this thread. I never used it.

The problem was caused by a conflicting constraint: axi_clk was defined as 100MHz in the IP core in a not-OOC XDC file, but in the top design, the frequency for that same clock was correctly derived from clock wizard (108MHz). Top design's constraint didn't override that of IP core, so Vivado was analyzing timing inside IP core taking 100MHz as destination clock's frequency, despite of that clock being attached to a PLL with 108MHz clock output.

 

Thanks!

0 Kudos