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
Observer tstone_sz
Observer
17,208 Views
Registered: ‎09-05-2013

how to solve clock path skew high hold violation?

Jump to solution

hi xilinx, we are doing the asic prototyping, we meet the hold violation because of the two issue.

 

1, hold timing requirement 0

 

pls note that clk_24MHz and clk_48MHz are sourced by one 100MHz, they are same phase,clock path skew is slow.

 

how can i deal with it  ?you can found that in the attachment k80_256_low.v

 

Hold Paths: TS_clkgen_k80_mcmm_clkout1 = PERIOD TIMEGRP "clkgen_k80_mcmm_clkout1"
TS_clk_in / 0.24 HIGH 50%;
--------------------------------------------------------------------------------

Paths for end point usb_otg/U_USB_CLOCK_RECOVERY/U_USB_CLK_RECOVERY_CDC/miss_sof_rough_clk_cross[0] (SLICE_X38Y177.AX), 1 path
--------------------------------------------------------------------------------
Slack (hold path): -0.468ns (requirement - (clock path skew + uncertainty - data path))
Source: usb_otg/U_USB_CLOCK_RECOVERY/U_USB_CLK_RECOVERY_CDC/miss_sof_rough_ipg_clk_cross[1] (FF)
Destination: usb_otg/U_USB_CLOCK_RECOVERY/U_USB_CLK_RECOVERY_CDC/miss_sof_rough_clk_cross[0] (FF)
Requirement: 0.000ns
Data Path Delay: 0.201ns (Levels of Logic = 0)
Clock Path Skew: 0.321ns (1.494 - 1.173)
Source Clock: clk_24MHz rising at 0.000ns
Destination Clock: clk_48MHz rising at 0.000ns
Clock Uncertainty: 0.348ns

Clock Uncertainty: 0.348ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.070ns
Discrete Jitter (DJ): 0.450ns
Phase Error (PE): 0.120ns

Minimum Data Path at Fast Process Corner: usb_otg/U_USB_CLOCK_RECOVERY/U_USB_CLK_RECOVERY_CDC/miss_sof_rough_ipg_clk_cross[1] to usb_otg/U_USB_CLOCK_RECOVERY/U_USB_CLK_RECOVERY_CDC/miss_sof_rough_clk_cross[0]
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X37Y178.AQ Tcko 0.141 usb_otg/U_USB_CLOCK_RECOVERY/miss_sof_rough_ipg_clk_cross[1]
usb_otg/U_USB_CLOCK_RECOVERY/U_USB_CLK_RECOVERY_CDC/miss_sof_rough_ipg_clk_cross[1]
SLICE_X38Y177.AX net (fanout=3) 0.130 usb_otg/U_USB_CLOCK_RECOVERY/miss_sof_rough_ipg_clk_cross[1]
SLICE_X38Y177.CLK Tckdi (-Th) 0.070 usb_otg/U_USB_CLOCK_RECOVERY/U_USB_CLK_RECOVERY_CDC/miss_sof_rough_clk_cross[1]
usb_otg/U_USB_CLOCK_RECOVERY/U_USB_CLK_RECOVERY_CDC/miss_sof_rough_clk_cross[0]
------------------------------------------------- ---------------------------
Total 0.201ns (0.071ns logic, 0.130ns route)
(35.3% logic, 64.7% route)

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

 

 

 

 

2, the high clock path skew issue

this issue is caused by high clock path skew. because the asic have much gated clock, we can't put every clock as bufg.

 

so generated this issue. how can deal with it?

 

Hold Paths: TS_clkgen_k80_mcmm_clkout2 = PERIOD TIMEGRP "clkgen_k80_mcmm_clkout2"
TS_clk_in / 0.12 HIGH 50%;
--------------------------------------------------------------------------------

Paths for end point d_ip_llwu_syn/wufilt[2].llwu_wufilt_pin/genblk1.q_wupin_negedge (SLICE_X106Y121.C6), 1 path
--------------------------------------------------------------------------------
Slack (hold path): -15.487ns (requirement - (clock path skew + uncertainty - data path))
Source: d_ip_llwu_syn/filt_reg[2].llwu_ips_fe_reg/q_reg[1] (FF)
Destination: d_ip_llwu_syn/wufilt[2].llwu_wufilt_pin/genblk1.q_wupin_negedge (FF)
Requirement: 0.000ns
Data Path Delay: 0.609ns (Levels of Logic = 1)
Clock Path Skew: 15.513ns (13.200 - -2.313)
Source Clock: clk_12MHz rising at 0.000ns
Destination Clock: d_ip_llwu_syn/N_366_mux_i rising at 0.000ns
Clock Uncertainty: 0.583ns

Clock Uncertainty: 0.583ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.070ns
Discrete Jitter (DJ): 0.504ns
Phase Error (PE): 0.328ns

Minimum Data Path at Slow Process Corner: d_ip_llwu_syn/filt_reg[2].llwu_ips_fe_reg/q_reg[1] to d_ip_llwu_syn/wufilt[2].llwu_wufilt_pin/genblk1.q_wupin_negedge
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X109Y123.BQ Tcko 0.367 d_ip_llwu_syn.llwu_fe[5]
d_ip_llwu_syn/filt_reg[2].llwu_ips_fe_reg/q_reg[1]
SLICE_X106Y121.C6 net (fanout=3) 0.412 d_ip_llwu_syn.llwu_fe[5]
SLICE_X106Y121.CLK Tah (-Th) 0.170 d_ip_llwu_syn.wufilt_0
d_ip_llwu_syn/wufilt[2].llwu_wufilt_pin/genblk1.q_wupin_negedge_e
d_ip_llwu_syn/wufilt[2].llwu_wufilt_pin/genblk1.q_wupin_negedge
------------------------------------------------- ---------------------------
Total 0.609ns (0.197ns logic, 0.412ns route)
(32.3% logic, 67.7% route)

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

 

thank you

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Observer tstone_sz
Observer
27,925 Views
Registered: ‎09-05-2013

Re: how to solve clock path skew high hold violation?

Jump to solution

hi avrumw and gszakacs, thank you very much for your detail explian.

 

that's a general describation for asic prototyping for me. i will study it.

 

thanks again! 

View solution in original post

7 Replies
Professor
Professor
17,189 Views
Registered: ‎08-14-2007

Re: how to solve clock path skew high hold violation?

Jump to solution

Since you haven't had a reply yet, it's likely that there aren't many ASIC prototyping experts on these forums and you may be best off talking to your FAE.

 

If this were designed to target an FPGA, then the stock answer is to take all simply related clocks like 12.5 25 and 50 MHz, and run them all from a higher frequency clock like 100 MHz using clock enables.  However if you're trying to verify the ASIC code, you'd really want this to happen "under the hood" to make sure that you haven't introduced any design changes unintentionally.  I believe there are tools that do this for ASIC prototyping, but I don't personally have any experience with them.

-- Gabor
0 Kudos
Observer tstone_sz
Observer
17,177 Views
Registered: ‎09-05-2013

Re: how to solve clock path skew high hold violation?

Jump to solution

hi gszakacs, could you tell me if for fpga target project, how will you solve these two issues, so i can reference them.

0 Kudos
Guide avrumw
Guide
17,165 Views
Registered: ‎01-23-2009

Re: how to solve clock path skew high hold violation?

Jump to solution

tstone_sz,

 

You have run into what is almost always the biggest problem in doing ASIC prototyping in an FPGA.

 

In an ASIC you can (and these days, increasingly do) have an immense number of clock domains. Clock trees can be built by the clock insertion tool to produce any number of trees, with mutliple groups of trees being skew matched (for synchronous operation between them) in spite of having

  - different harmonic relationships (clocks that are multiples of eachother)

  - clocks that are gated for power reduction purposes

    - power management is critical in larger ASIC designs

 

The result is (as you have here) the need for lots of "different" clock trees that have the requirements of being synchronous.

 

However, in FPGAs, clock trees are not "built", but are fixed resources within the FPGA with specific buffers (which have specific capabilities) driving them. And they are finite - most modern FPGAs have 32 global clock domains (and no more).

 

So, how do you map the ASIC, which may have many dozen clock domains with with specific skew requirements between them, to the FPGA which has only a finite number of skew matched clock trees.

 

That is the fundamental problem in ASIC prototyping. There isn't a single answer to the question...

 

In an ideal situation, you map all the ASIC clock domains to global FPGA clock domains, using the MMCMs, BUFGMUX and BUFCE resources to replicate the synchronous domains you need. But, you only have 32 global domains. A good start is to remove all the power gating clock domains - this usually represents a large number of domains in the ASIC. With this done, you won't be able to emulate your power management processes in the FPGA, but you have a chance to get the number of domains down low enough to fit in the BUFGs. The tools may (or may not) be able to help you do this - there is an option in Vivado synthesis for "gated_clock_conversion" which may be able to remove some clock gates and replace them with the CEs on FFs (at the cost of huge routing expense). I think Synopsys has a tool that is more focussed on ASIC prototyping (Amplify?) - but ultimately it is your challenge to make this work.

 

You may also be able to take advantage of the BUFH and BUFHCE - this can allow you to generate smaller gated (and, if intellegently done, divided) domains that are synchronous to the source domain.

 

What won't work is (as you have seen) simply trying to let the FPGA tools implement the ASIC clock structure as is. You end up with clock signals leaving clock trees to get gated or divided. Once that happens, your new clock still needs to be a clock (since it drives FFs). This can be done one of two ways (neither of which work)

  - the new clock is a local clock; it doesn't use a BUFG or BUFH and hence ends up in local routing

    - this uses tons of routing resources, has terrible skew even among different destinations of the same clock, and has significant skew with the source (ungated) clock

  - the new clock gets re-buffered on a BUFG or BUFH; the divided/gated clock goes through fabric routing to reach the input of a BUFG/BUFH and then gets distributed to the FFs being driven by the gated/new clock

    - this has fine skew between the different loads of the same clock, but a significant skew to the original clock; the delay of a BUFG and global clock network is measured in nanoseconds


Both of these are going to have signficant skew between the gated/divided clock and the original (source) clock. But in the ASIC, these clock trees will be balanced by the clock insertion tool. These will behave differently - the functionality expected in the ASIC will not work in the FPGA. Period.

 

This is fundamental to the FPGA architecture, and you will have to find a way to solve it.

 

One interesting note is that UltraScale is different. The clocking resources in UltraScale are significantly different than in any previous FPGA family. The clock resources are far more flexible and segmented, and allows some "ASIC-like" clocking structures. While the problem of mapping ASIC clock domains to FPGAs will still not be a trivial task in UltraScale, there will be far more that you can do in that technology than in previous ones.

 

Avrum

Tags (1)
Professor
Professor
17,152 Views
Registered: ‎08-14-2007

Re: how to solve clock path skew high hold violation?

Jump to solution

@tstone_sz wrote:

hi gszakacs, could you tell me if for fpga target project, how will you solve these two issues, so i can reference them.


The two issues are really just one issue, i.e. clock distribution.  The excessive hold time results from the different buffer delays or from the use of local routing resources.

 

The best thing you can do is to reduce the number of global clocks to what is allowed in the architecture, usually 16.  Gated clocks should be replaced with clock enables.  i.e. the clock gating gets done within each synchronous element of the FPGA rather than in the clock distribution network as it would be in the ASIC.  In the FPGA this happens "for free" with the exception of the routing resources taken by the clock enable.  What you really gain is the low skew clock delivery, while the clock enable has more leeway for skew but can use normal routing resources.

 

Now if you have a lot of code written that doesn't account for clock enables, this can be a major change to the RTL unless you have tools that can automate that process for you.  Essentially where you have a gated clock, instead of supplying that gated clock to all synchronous elements, you need to supply the original clock and then use the signal that would have gated the clock as a clock enable input instead.  This may have some other timing implications, since a clock gating signal usually needs to be synchronous the the opposite clock edge from the logic.  So if the clock is fast, you lose some setup time to the clock enables in the FPGA vs using a clock enable generated on the same clock edge that the logic uses.  If the clock is slow enough that the 1/2 cycle of setup is enough, then it gets simpler.

 

So supposing you have a high speed clock, sys_clk, and created a gating signal like:

 

@always @ (negedge sys_clk) sys_div_2 <= !sys_div_2;

 

and then used (sys_clk & sys_div_2) to clock a pile of logic like:

 

assign sys_div2_clk = sys_clk & sys_div_2;

 

@always @ (posedge sys_div2_clk)

  begin

     lots of assignments;

  end

 

You'd want to translate that to:

 

@always @ (posedge sys_clk)  // edited, thanks Avrum

if (sys_div_2)

  begin

    lots of assignments;

  end

 

If you can use this method to reduce the overall clock number to something the FPGA can handle with normal clocking resources, then you're pretty much home free.  But as you can see, this gets into a lot of code editing if you don't already have clock enable inputs to your downstream logic.  And of course you don't want to do so much hand-editing that you're not sure of what you're verifying anymore.

-- Gabor
Guide avrumw
Guide
17,148 Views
Registered: ‎01-23-2009

Re: how to solve clock path skew high hold violation?

Jump to solution

Presumably that last part should be

 

always @ (posedge sys_clk)

if (sys_div_2)

  begin

    lots of assignments;

  end

Observer tstone_sz
Observer
27,926 Views
Registered: ‎09-05-2013

Re: how to solve clock path skew high hold violation?

Jump to solution

hi avrumw and gszakacs, thank you very much for your detail explian.

 

that's a general describation for asic prototyping for me. i will study it.

 

thanks again! 

View solution in original post

Xilinx Employee
Xilinx Employee
17,113 Views
Registered: ‎02-26-2014

Re: how to solve clock path skew high hold violation?

Jump to solution

Hi,

 

In general hold violations can come only when clock path is spoiled with some logic.

 

When I did ASIC prototyping I made some changes to the clock path. I had access to the RTL for modifications.

1. Removed all ASIC clock gating cells.

2. Replaced all the clock modification logic by clocking modules of FPGA

    For example replaced a clock divider with an MMCM

3. Removed cascaded BUFGs

4. Have a constraint for false path for which there are some false timimg vilations.

    For example a path starting from MMCM clock output to D input of a Flip Flop.

 

Reagrds,

Ravi