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: 
Highlighted
Participant sarit8
Participant
4,284 Views
Registered: ‎08-15-2016

mmcm timing issues

Jump to solution

In my timimng report I can see that there are timing issues with a path which its source is:

clk_rst_ctrl_i/clk_wiz_0_i/inst/mmcm_adv_ins/CLOCKOUT1

 

Where clk_rst_ctrl is the block which the reset synchronizer is.

 

I can see the the number of the fanout is high (15136).

 

How can I handle this timing issue? 

 

Tags (2)
mmcm_clk.PNG
reset_sync.PNG
0 Kudos
1 Solution

Accepted Solutions
Guide avrumw
Guide
7,106 Views
Registered: ‎01-23-2009

Re: mmcm timing issues

Jump to solution

How can I eliminate the path which contain the BUFG?

 
The problem isn't with the BUFG or the MMCM, it is in the fact that you are driving combinatorial logic with a clock. A clock should only drive the clock inputs of clocked cells.
 
The cell  rx_top_i/demoder_i/corr_res_i/wr_over_rd_i_1 is a LUT_5 which is taking the output of the BUFG as an input. You shouldn't do this. You have to go through your code and find out where you are using the clock anywhere other than the
 
always @(posedge clk)  (Verilog) or
 
if (rising_edge (clk))  (VHDL)
 
This is incorrect and has to be fixed.
 
Avrum

View solution in original post

0 Kudos
6 Replies
Moderator
Moderator
4,247 Views
Registered: ‎09-15-2016

Re: mmcm timing issues

Jump to solution

Hi @sarit8

 

Can you paste the timing report of one of the failing path here?

 

Regards

Rohit

 

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

Regards
Rohit
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

0 Kudos
Participant sarit8
Participant
4,237 Views
Registered: ‎08-15-2016

Re: mmcm timing issues

Jump to solution

in Delay Paths
--------------------------------------------------------------------------------------
Slack (VIOLATED) : -0.347ns (arrival time - required time)
Source: clk_rst_ctrl_i/clk_wiz_0_i/inst/mmcm_adv_inst/CLKOUT1
(clock source 'clk_o125_clk_wiz_0' {rise@0.000ns fall@4.000ns period=8.000ns})
Destination: rx_top_i/demoder_i/corr_res_i/wr_over_rd_reg/D
(rising edge-triggered cell FDRE clocked by clk_o125_clk_wiz_0 {rise@0.000ns fall@4.000ns period=8.000ns})
Path Group: clk_o125_clk_wiz_0
Path Type: Hold (Min at Fast Process Corner)
Requirement: 0.000ns (clk_o125_clk_wiz_0 rise@0.000ns - clk_o125_clk_wiz_0 rise@0.000ns)
Data Path Delay: 1.365ns (logic 0.071ns (5.203%) route 1.294ns (94.797%))
Logic Levels: 2 (BUFG=1 LUT5=1)
Clock Path Skew: 1.591ns (DCD - SCD - CPR)
Destination Clock Delay (DCD): 1.258ns
Source Clock Delay (SCD): -0.338ns
Clock Pessimism Removal (CPR): 0.006ns

Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk_o125_clk_wiz_0 rise edge)
0.000 0.000 r
W11 0.000 0.000 r adc_outclkp (IN)
net (fo=0) 0.000 0.000 rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/clk_in_p
W11 r rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/ibufds_clk_inst/I
W11 IBUFDS (Prop_ibufds_I_O) 0.444 0.444 r rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/ibufds_clk_inst/O
net (fo=2, routed) 0.206 0.650 rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/clk_in_int
BUFR_X0Y1 r rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/clkout_buf_inst/I
BUFR_X0Y1 BUFR (Prop_bufr_I_O) 0.093 0.744 r rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/clkout_buf_inst/O
net (fo=67, routed) 0.214 0.958 clk_rst_ctrl_i/clk_wiz_0_i/inst/clk_i125
MMCME2_ADV_X0Y0 r clk_rst_ctrl_i/clk_wiz_0_i/inst/mmcm_adv_inst/CLKIN1
------------------------------------------------------------------- -------------------
MMCME2_ADV_X0Y0 MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT1)
-1.296 -0.338 r clk_rst_ctrl_i/clk_wiz_0_i/inst/mmcm_adv_inst/CLKOUT1
net (fo=1, routed) 0.648 0.309 clk_rst_ctrl_i/clk_wiz_0_i/inst/clk_o125_clk_wiz_0
BUFGCTRL_X0Y0 r clk_rst_ctrl_i/clk_wiz_0_i/inst/clkout2_buf/I
BUFGCTRL_X0Y0 BUFG (Prop_bufg_I_O) 0.026 0.335 r clk_rst_ctrl_i/clk_wiz_0_i/inst/clkout2_buf/O
net (fo=15137, routed) 0.646 0.981 rx_top_i/demoder_i/corr_res_i/clk_o125
SLICE_X76Y65 r rx_top_i/demoder_i/corr_res_i/wr_over_rd_i_1/I4
SLICE_X76Y65 LUT5 (Prop_lut5_I4_O) 0.045 1.026 f rx_top_i/demoder_i/corr_res_i/wr_over_rd_i_1/O
net (fo=1, routed) 0.000 1.026 rx_top_i/demoder_i/corr_res_i/wr_over_rd_i_1_n_0
SLICE_X76Y65 FDRE f rx_top_i/demoder_i/corr_res_i/wr_over_rd_reg/D
------------------------------------------------------------------- -------------------

(clock clk_o125_clk_wiz_0 rise edge)
0.000 0.000 r
W11 0.000 0.000 r adc_outclkp (IN)
net (fo=0) 0.000 0.000 rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/clk_in_p
W11 IBUFDS r rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/ibufds_clk_inst/I
W11 IBUFDS (Prop_ibufds_I_O) 0.480 0.480 r rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/ibufds_clk_inst/O
net (fo=2, routed) 0.311 0.791 rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/clk_in_int
BUFR_X0Y1 BUFR r rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/clkout_buf_inst/I
BUFR_X0Y1 BUFR (Prop_bufr_I_O) 0.255 1.046 r rx_top_i/adc_if_i/adc_ddr_lvds_i/inst/clkout_buf_inst/O
net (fo=67, routed) 0.246 1.292 clk_rst_ctrl_i/clk_wiz_0_i/inst/clk_i125
MMCME2_ADV_X0Y0 MMCME2_ADV r clk_rst_ctrl_i/clk_wiz_0_i/inst/mmcm_adv_inst/CLKIN1
MMCME2_ADV_X0Y0 MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT1)
-1.625 -0.333 r clk_rst_ctrl_i/clk_wiz_0_i/inst/mmcm_adv_inst/CLKOUT1
net (fo=1, routed) 0.700 0.368 clk_rst_ctrl_i/clk_wiz_0_i/inst/clk_o125_clk_wiz_0
BUFGCTRL_X0Y0 BUFG r clk_rst_ctrl_i/clk_wiz_0_i/inst/clkout2_buf/I
BUFGCTRL_X0Y0 BUFG (Prop_bufg_I_O) 0.029 0.397 r clk_rst_ctrl_i/clk_wiz_0_i/inst/clkout2_buf/O
net (fo=15137, routed) 0.862 1.258 rx_top_i/demoder_i/corr_res_i/clk_o125
SLICE_X76Y65 FDRE r rx_top_i/demoder_i/corr_res_i/wr_over_rd_reg/C
clock pessimism -0.006 1.252
SLICE_X76Y65 FDRE (Hold_fdre_C_D) 0.121 1.373 rx_top_i/demoder_i/corr_res_i/wr_over_rd_reg
-------------------------------------------------------------------
required time -1.373
arrival time 1.026
-------------------------------------------------------------------
slack -0.347

0 Kudos
Guide avrumw
Guide
4,233 Views
Registered: ‎01-23-2009

Re: mmcm timing issues

Jump to solution

So, first, the diagrams that you attach to your forum posts are not particularly easy to understand. I don't know what tool (or if they are hand drawn) these diagrams come from, but it is far better to post schematics from Vivado...

 

Similarly, it is very hard to follow timing reports that are pasted as text into the body of the forum post. At very least they should be placed in an "Insert code" window, so that they are not line wrapped, and use a fixed point font.

 

Next the path that we can see has a connection path from the output of the MMCM to (through a BUFG) to combinatorial logic. This is bad design practice, and causes timing problems - this is probably the cause of the failure you are seeing. You need to eliminate this path - clocks should only go to dedicated clock resources (MMCM, PLL, clock buffers) and clock pins of clocked cells (flip-flops, RAMs, DSP48 cells).

 

Finally, you have a BUFR inserted between your clock input pin and the MMCM. While not illegal, this is unusual, and has some significant consequences. Are you sure this clock structure is what you want?

 

Avrum

0 Kudos
Participant sarit8
Participant
4,172 Views
Registered: ‎08-15-2016

Re: mmcm timing issues

Jump to solution

I attached the relevant schematic part of the clk_wiz_0 (which is ip from xilinx).

How can I eliminate the path which contain the BUFG?

clk_wiz.PNG
0 Kudos
Participant sarit8
Participant
4,169 Views
Registered: ‎08-15-2016

Re: mmcm timing issues

Jump to solution

By the way according xilinx A global buffer distributes high fanout signals throughout a device.... so it supposed to help timing issues.

 

Usage
Global buffers are most commonly used for clock nets to provide the least amount of skew possible between registers that are physically located large distances apart. You can also use them to provide quick access to control signals in high speed applications.
Instantiation is recommended for global buffers. You can instantiate the component as follows:
  •  For schematic designs, instantiate the Xilinx® Unified Library symbol.
  •  For HDL designs, do either of the following:
    •  Use the instantiation templates provided in the Libraries Guides.
    •  Use the instantiation templates provided with the Project Navigator Language Templates, which are described in Working with Language Templates.
Note Global buffers are automatically inferred on clock signals. If a non-clock signal is constrained to a global clock pin, the global buffer must be manually instantiated.
0 Kudos
Guide avrumw
Guide
7,107 Views
Registered: ‎01-23-2009

Re: mmcm timing issues

Jump to solution

How can I eliminate the path which contain the BUFG?

 
The problem isn't with the BUFG or the MMCM, it is in the fact that you are driving combinatorial logic with a clock. A clock should only drive the clock inputs of clocked cells.
 
The cell  rx_top_i/demoder_i/corr_res_i/wr_over_rd_i_1 is a LUT_5 which is taking the output of the BUFG as an input. You shouldn't do this. You have to go through your code and find out where you are using the clock anywhere other than the
 
always @(posedge clk)  (Verilog) or
 
if (rising_edge (clk))  (VHDL)
 
This is incorrect and has to be fixed.
 
Avrum

View solution in original post

0 Kudos