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: 
Visitor avail123
Visitor
8,269 Views
Registered: ‎02-05-2013

understanding clock skew in timing report

I am using part number a V5FX130.

 

I am capturing source-synchronous data using and ISERDES_NODELAY primative with a BUFIO and BUFR to drive the clock inputs of the ISERDES; in addition the BUFR also drives some CLB FF which perform another demux stage. At this point I want to hand the data off from the local BUFR clock domain to the global clock domain that operates at the same frequency.

I do not have an input clock on a "GC" pin; so to create the global clock I routed the local BUFR output clock to a BUFG, and then to a DCM to generate a global clock. I understand this is not a recommended approach but I am tring to avoid the use a FIFO in the design. My clock period is 7ns; although I expected to see skew between the local BUFR clock and global clock from the DCM I did not expect it to be greater than 7ns. The timing report (below) is showing 10.712ns of skew....how is this number calculated? It is causing the design to fail hold time by a large margin. I don't understand how the tools are calculating the clock path skew: (14.735ns - 4.023ns = 10.712ns)

 

--------------------------------------------------------------------------------
Slack (hold path):      -10.390ns (requirement - (clock path skew + uncertainty - data path))
  Source:               U169_DRH/U4_DMUX_BI/sample_Q3B[1] (FF)
  Destination:          U169_DRH/U4_DMUX_BI/frame64b[9] (FF)
  Requirement:          0.000ns
  Data Path Delay:      0.477ns (Levels of Logic = 0)
  Clock Path Skew:      10.712ns (14.735 - 4.023)
  Source Clock:         U169_DRH/clk142_to_BQ rising
  Destination Clock:    U169_DRH/clk142 rising
  Clock Uncertainty:    0.155ns

  Clock Uncertainty:          0.155ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter (TSJ):  0.070ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.120ns
    Phase Error (PE):           0.060ns

  Minimum Data Path: U169_DRH/U4_DMUX_BI/sample_Q3B[1] to U169_DRH/U4_DMUX_BI/frame64b[9]
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    SLICE_X2Y92.BQ       Tcko                  0.584   U169_DRH/U4_DMUX_BI/sample_Q3B(3)
                                                       U169_DRH/U4_DMUX_BI/sample_Q3B[1]
    SLICE_X3Y92.BX       net (fanout=1)        0.285   U169_DRH/U4_DMUX_BI/sample_Q3B(1)
    SLICE_X3Y92.CLK      Tckdi       (-Th)     0.392   U169_DRH/Bdin_re_dmux(11)
                                                       U169_DRH/U4_DMUX_BI/frame64b[9]
    -------------------------------------------------  ---------------------------
    Total                                      0.477ns (0.192ns logic, 0.285ns route)
                                                       (40.3% logic, 59.7% route)

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

 

Thanks for the help

0 Kudos
9 Replies
Professor
Professor
8,264 Views
Registered: ‎08-14-2007

Re: understanding clock skew in timing report

A BUFG has significant propagation delay because it needs to drive a large distributed net.  This

is a bit like using route length matching on a PC board.  Since the BUFG needs to have low skew

between its outputs, it needs to have a delay it can meet at the farthest load, but apply the same

delay to all loads.  So it is not surprising to have several nanoseconds of delay in this path.

Also, I assume your DCM has another BUFG on the output.  If you don't have the output BUFG

in the feedback path, then your final clock net could have two BUFG delays in it.

 

Just out of curiosity, why did you add a DCM rather than just using the output of the first

BUFG which was driven by the BUFR?  If the intent was to remove the delay of the first

BUFG, then you may need to make a phase adjustment to the DCM output.

-- Gabor
0 Kudos
Visitor avail123
Visitor
8,259 Views
Registered: ‎02-05-2013

Re: understanding clock skew in timing report

Hi Gabor,

 

I am providing the feedback path to the DCM through a BUFG so I beleive I only have one BUFG delay on the output clock.

 

Your comment about the DCM is a good one- I could probably remove it from the design and drive all of the processing off the BUFG that is driven by the BUFR....but wouldn't this still result is a large skew between the local BUFR clock and output of the BUFG? Does using a DCM (at least in this scenario) add more skew? I thought the DCM would align it's output clock with it's input clock and only the skew from BUFR output to DCM would uncorrected for....

 

thanks

0 Kudos
Professor
Professor
8,251 Views
Registered: ‎08-14-2007

Re: understanding clock skew in timing report

First, if you used a clocking wizard to create your DCM, you should look through it to

make sure you really have the BUFG in the feedback path.  Also, if I'm not mistaken

the V5 has some phase related settings (system synchronous v. source synchronous)

that can affect the delay through the DCM + BUFG.  Theoretically if the BUFG is in

the feedback path it whould not add delay beyond the first BUFG, but it could add

some clock uncertainty (jitter) which gets included in the timing analysis.  The DCM

does have the capability to change the phase of the output clock, so you could

use that to subtract the delay of the input BUFG, but you might need to play around

with the settings until you get something that works.  Another question is why you

are worried about using a FIFO for this clock crossing.  Is it just the latency or

are you concerned about resources?

-- Gabor
0 Kudos
Visitor avail123
Visitor
8,245 Views
Registered: ‎02-05-2013

Re: understanding clock skew in timing report

Checking my VHDL for the DCM- it was set to source_synchronous.....which sets the delay tap to 0 so it wasn't adjusting for any skew from input to output.....thanks for catching that. Hopefully when I run with system synchronous I will get skew numbers that make sense...or even allow the design to meet hold requirements.

 

The reason I have been trying to avoid a FIFO is that I actually have a few channels of I/Q data coming into the FPGA all through the ISERDES; each channel is received the same way as described above. For proper processing of the data I need to keep not only I/Q within a channel aligned; but channel to channel needs to be aligned. With a FIFO it is possible one channel could get ahead of another by a clock cycle or two, or three....so although the FIFO makes the timing problem much easier to solve it complicates the processing of the data if  they are few clock cycles out of alignment in time....

 

Thanks

0 Kudos
Professor
Professor
8,240 Views
Registered: ‎08-14-2007

Re: understanding clock skew in timing report

Do all of the channels come in on the same clock?  If so, the FIFO could cover all of them

and any data you read out would be data that came in on the same clock.  If not, then I don't see how

avoiding the FIFO helps.

-- Gabor
0 Kudos
Visitor avail123
Visitor
8,235 Views
Registered: ‎02-05-2013

Re: understanding clock skew in timing report

All of the channels come in on seperate clocks that have been aligned....so in theory the clocks arriving with thier respective data are all rising edge aligned (neglecting skew in the PCB). The inputs are spread over more than 3 clock regions; so can 1 BUFR drive a single FIFO that is accepting data from other clock regions? I guess i was stuck in the thought of trying to synchronize multiple FIFOs

 

The BUFRs each have a divide; is the inital state of the BUFR divide guaranteed to be same across multiple BUFRs if their CLR inputs are tied low? i.e. do they all start low (or high)?

 

Thanks again for your help

0 Kudos
Professor
Professor
8,233 Views
Registered: ‎08-14-2007

Re: understanding clock skew in timing report

The V5 User Guide says that a BUFR can drive up to three adjacent clock regions.  You'd

have to look at your design layout to see if the three regions are adjacent.  If not you might still

have an option to place the FIFO in a central clock region and route from the input flops of

all three regions into the FIFO on the central BUFR.  Whether this will work depends on how

much routing delay you get from the farthest input flop and of course how much time you

have (clock period - clock skew).  If your input clock is not too fast, the routing distance from

the other clock regions might work in your advantage to prevent clock skew related hold

time issues.

 

As to the relative state of BUFR dividers, I have no idea.  Can you guarantee that they

get released from reset on the same clock edge (in all three domains)?

-- Gabor
0 Kudos
Visitor avail123
Visitor
8,212 Views
Registered: ‎02-05-2013

Re: understanding clock skew in timing report

The number of inputs i have span more than 3 clock regions so if I were to try to use FIFOs to transition from the local to global clock domains I would have to use multiple FIFO blocks. The issue then becomes how do I ensure that each FIFO block comes out of reset synchronously with the others....

 

0 Kudos
Professor
Professor
8,205 Views
Registered: ‎08-14-2007

Re: understanding clock skew in timing report


@avail123 wrote:

The number of inputs i have span more than 3 clock regions so if I were to try to use FIFOs to transition from the local to global clock domains I would have to use multiple FIFO blocks. The issue then becomes how do I ensure that each FIFO block comes out of reset synchronously with the others....

 


I don't think you quite understood what I was suggesting for the common FIFO.  While the

input registers need to be in three independent regions driven by three different BUFR's,

the FIFO itself would all live in just one region.

 

This would only work if, as you said in your previous post, the three input clocks were aligned

well enough to avoid setup of hold timing in the clock crossings internal to the FPGA.

 

-- Gabor
0 Kudos