cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
onemanshow
Observer
Observer
11,544 Views
Registered: ‎05-20-2009

large clock path skew

Hello,

 

   I have a PLL with two output frequency.  One is 125Mhz and the other one is 76Mhz. Input of PLL comes from external pin with frequency of 125Mhz. These two outputs are not related, so I defined these two outputs into two groups and used TIG for false path. That all worked fine. However 76Mhz groupd has unusually large clock path skew ,

 

Clock Path Skew:      -5.056ns (1.420 - 6.476) 

 

  while 125Mhz has acceptable clock path skew

 

Clock Path Skew:      -0.635ns (1.465 - 2.100)

 

    Since both outputs comes from same PLL, I would expect clock skew should be similar. However  there is huge difference and 75Mhz group is having problem meeting timing. Any comments or help would be great. Thanks

 

 

0 Kudos
13 Replies
paullee3
Xilinx Employee
Xilinx Employee
11,537 Views
Registered: ‎08-12-2008

Are there BUFG on both PLL outputs?

0 Kudos
onemanshow
Observer
Observer
11,527 Views
Registered: ‎05-20-2009

Yes. This PLL is generated using coregen with global buffer for outputs enabled. I also manually checked PLL design.

0 Kudos
paullee3
Xilinx Employee
Xilinx Employee
11,521 Views
Registered: ‎08-12-2008

Can you paste the full portion of the reported path for your 75 & 125MHz clock, I paste an example below,

 

Paths for end point pcie_bridge_m/pcie_wrap_m/pcie_core_m/pcie_clocking_i/GEN2_LINK.pipe_clk_bufgmux (BUFGCTRL_X0Y12.CE1), 1 path

--------------------------------------------------------------------------------

Slack (setup path): -2.523ns (requirement - (data path - clock path skew + uncertainty))

Source: pcie_bridge_m/pcie_wrap_m/pcie_core_m/pcie_clocking_i/GEN2_LINK.sel_lnk_rate_delay (FF)

Destination: pcie_bridge_m/pcie_wrap_m/pcie_core_m/pcie_clocking_i/GEN2_LINK.pipe_clk_bufgmux (OTHER)

Requirement: 4.000ns

Clock Path Skew: -2.684ns (0.987 - 3.671)

Source Clock: pcie_bridge_m/pcie_wrap_m/pcie_core_m/pipe_clk rising at 0.000ns

Destination Clock: pcie_bridge_m/pcie_wrap_m/pcie_core_m/pcie_clocking_i/clk_250 rising at 4.000ns

Clock Uncertainty: 0.289ns

Data Path Delay: 3.550ns (Levels of Logic = 1)

 

0 Kudos
onemanshow
Observer
Observer
11,473 Views
Registered: ‎05-20-2009

75Mhz clock path:

 

Slack:                  -4.415ns (requirement - (data path - clock path skew + uncertainty))
  Source:               dut_core_inst/lti_m8051_inst/m8051tc_top_inst/U_cpu_top/U_regblk/radr_4 (FF)
  Destination:          dut_core_inst/lti_m8051_inst/m8051_bar_inst/esfr_dout_l_7 (FF)
  Requirement:          13.000ns
  Data Path Delay:      11.484ns (Levels of Logic = 14)
  Clock Path Skew:      -5.845ns (2.252 - 8.097)
  Source Clock:         dut_core_inst/lti_m8051_inst/m8051tc_top_inst/clk_cpu rising at 0.000ns
  Destination Clock:    tmp_clk rising at 13.000ns
  Clock Uncertainty:    0.086ns

 

125Mhz clock path:

 

Slack:                  -2.639ns (requirement - (data path - clock path skew + uncertainty))
  Source:               dut_core_inst/usb_inst/epc_ss_inst/epc_tx_inst/dp_tx_inst/dp_ep_buff_start_0 (FF)
  Destination:          dut_core_inst/usb_inst/epc_ss_inst/epc_tx_inst/dp_tx_inst/curr_pkt_retry (FF)
  Requirement:          8.000ns
  Data Path Delay:      10.507ns (Levels of Logic = 13)
  Clock Path Skew:      -0.052ns (0.704 - 0.756)
  Source Clock:         A5_B47_OBUF rising at 0.000ns
  Destination Clock:    A5_B47_OBUF rising at 8.000ns
  Clock Uncertainty:    0.080ns

0 Kudos
bassman59
Historian
Historian
11,465 Views
Registered: ‎02-25-2008

13 and 14 logic levels is a lot.

----------------------------Yes, I do this for a living.
0 Kudos
paullee3
Xilinx Employee
Xilinx Employee
11,461 Views
Registered: ‎08-12-2008

Source & Destination Clock for 125Mhz clock path refer to the same clock, A5_B47_OBUF.

While source & destination clock for 75Mhz clock path refer to 2 different clock, clk_cpu & tmp_clk, check to see how these 2 clocks are related to each other.

 

0 Kudos
onemanshow
Observer
Observer
11,459 Views
Registered: ‎05-20-2009

I just noticed the same thing. tmp_clk is the source clock. It goes through a mux(clock selection) and output becomes clk_cpu.  As default, clk_cpu is equal to tmp_clk. Is this mux causing this problem?

0 Kudos
paullee3
Xilinx Employee
Xilinx Employee
11,456 Views
Registered: ‎08-12-2008

the tool may use the other clock of the MUX to do the skew calculation, if you want the tool to select tmp_clk as the output of MUX, please consider to use PRIORITY keyword.

0 Kudos
onemanshow
Observer
Observer
11,451 Views
Registered: ‎05-20-2009

    Actually, its not a mux. Its a OR gate. We use a IP in our design and there are many clock gating logic. Do I have to replace all these clock gating logic with something FPGA specific elements?

0 Kudos
paullee3
Xilinx Employee
Xilinx Employee
6,595 Views
Registered: ‎08-12-2008

yes, gated clock is not a good thing for timing analysis, please avoid using them

0 Kudos
onemanshow
Observer
Observer
6,591 Views
Registered: ‎05-20-2009

I removed all the clock gating and now timing looks much better. These clock gating is necessary as final product. Is there anything I can do to have them and do proper timing analysis? Or is this limitatino of FPGA.

0 Kudos
paullee3
Xilinx Employee
Xilinx Employee
6,587 Views
Registered: ‎08-12-2008

please check to see if you can use the gated clock as Clock Enable for FF, that way, the design is more synchronous and more easy for the timing tool to analysis

0 Kudos
bassman59
Historian
Historian
6,563 Views
Registered: ‎02-25-2008

 


@onemanshow wrote:

I removed all the clock gating and now timing looks much better. These clock gating is necessary as final product. Is there anything I can do to have them and do proper timing analysis? Or is this limitatino of FPGA.


 

If you absolutely MUST use clock gating, use the BUFGCE primitive.

Otherwise, consider using clock enables.

----------------------------Yes, I do this for a living.
0 Kudos