cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Voyager
Voyager
298 Views
Registered: ‎04-12-2012

MMCM_Tstatphaoffset

Jump to solution

Hello,

In this interesting post ( answered by avrumw )

https://forums.xilinx.com/t5/Other-FPGA-Architecture/MMCM-clock-edge-alignment/td-p/918110

It's mentioned that the MMCM_Tstatphaoffset for the Kintex 7 family is 120ps.

I couldn't find this figure in any document.

Please post a link to a document that mentions this figure ( for 7 as well as Ultrascale FPGAs )

1 Solution

Accepted Solutions
271 Views
Registered: ‎01-22-2015

Re: MMCM_Tstatphaoffset

Jump to solution

@shaikon 

For Kintex-7 see Table 41 in DS182

For Kintex UltraScale see Table 36 in DS892

FYI – the only reference to “static phase offset” that I can find in the Clocking Guides for 7-Series (UG472) and UltraScale (UG572) is for “MMCM Counter Cascading” (ie. cascading the CLKOUT6 divider with the CLKOUT4 divider).  This seems different from the “static phase offset” (Tstatphaoffset) that Avrum describes in the post that you referenced.

Mark

View solution in original post

2 Replies
272 Views
Registered: ‎01-22-2015

Re: MMCM_Tstatphaoffset

Jump to solution

@shaikon 

For Kintex-7 see Table 41 in DS182

For Kintex UltraScale see Table 36 in DS892

FYI – the only reference to “static phase offset” that I can find in the Clocking Guides for 7-Series (UG472) and UltraScale (UG572) is for “MMCM Counter Cascading” (ie. cascading the CLKOUT6 divider with the CLKOUT4 divider).  This seems different from the “static phase offset” (Tstatphaoffset) that Avrum describes in the post that you referenced.

Mark

View solution in original post

Highlighted
131 Views
Registered: ‎01-22-2015

Re: MMCM_Tstatphaoffset

Jump to solution

@shaikon 

You have launched me into a many-question study - for which I thank you!

Here are more thoughts/findings on Tstatphaoffset.

We can click on the clock uncertainty number in a timing path report to see how the number was calculated.  As shown in the screenshot below, clock uncertainty is computed from Total System Jitter (TSJ), Discrete Jitter (DJ) and Phase Error (PE) using the formula, [(TSJ^2 + DJ^2)^1/2]/2 + PE.

clock_uncertainty.jpg

Using Vivado v2018.3, I created a Kintex-7 project where all clocks come from the outputs of a single MMCM.  A screen shot of the “Summary” tab from the Clocking Wizard v6.0 used to setup the MMCM is shown below:

CLKWIZ_6p0_Summary_.jpg

From this Vivado project and its timing (setup) path reports, I find the following:

  1. For Intra-Clock paths:
    1. Total System Jitter (TSJ) is always 0.071ns.
    2. Discrete-Jitter (DJ) equals the value of Pk-to-Pk Jitter (ps) for the clock from the Summary tab of the Clocking Wizard.
    3. Phase Error (PE) is always zero
  2. For Inter-Clock paths that are direct clock crossings:
    1. Total System Jitter (TSJ) is always 0.071ns.
    2. Discrete-Jitter (DJ): Here, two clocks are involved and Pk-to-Pk Jitter (ps) from the Summary tab of the Clocking Wizard is used.  However, Vivado looks at Pk-to-Pk Jitter for both clocks and sets DJ equal to the higher value of the two.
    3. Phase Error (PE) is always 0.120ns

From discussions elsewhere, I understand that non-zero values of PE in the clock uncertainty calculation are equal to the Tstatphaoffset that you have asked about.  I don’t know why non-zero values of PE are not equal to the Phase Error shown in the Clocking Wizard Summary tab – but that’s another issue.

When you configure the MMCM using the Clocking Wizard, you can specify desired phase differences between the output clocks.  I understand PE is a fixed (but unknown) offset from these desired phase differences.  That is, after the MMCM is powered and locked, the deviation from a desired phase difference is fixed at some value, T1.  The next time the MMCM is powered and locked, the deviation from a desired phase difference will probably be fixed at a new value, T2.  Both T1 and T2 are unknown – but both are presumably less than the value of Tstatphaoffset shown in the datasheet for your device.

The fact that PE is an offset (and not a time-varying random variable) is the reason that PE=0 and does not affect clock uncertainty and timing analysis for intra-clock paths.

Mark

0 Kudos