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: 
Explorer
Explorer
5,482 Views
Registered: ‎11-13-2009

MMCM Phase Delay not showing up in timing Report?

Jump to solution

I am using an MMCM to delay a clock which is leaving the FPGA to go to another device.  This is necessary to get the external device timing to match up with what I can reasonably make the FPGA do at the IO.

 

So the questions are: 

So does the timing engine take into account the Phase Delays that are assigned to MMCM's?  If so why doesn't it show up in this report below?

 

So a quick idea of what I am doing I have a internal reference clock called: clkout3 which is used for the majority of the logic for this interface.  This clock signal drives the input of an MMCM and provides an output clock with the phase delay of -76 degrees.  Here is a sample output of one of my timing reports to help get centered on this problem.

 

Slack (MET) : 3.615ns (required time - arrival time)
Source: spock_emulation_inst/Bridge_inst/lack_reg/C
(falling edge-triggered cell FDPE clocked by clk_out3_clk_synthesizer_1 {rise@0.000ns fall@25.000ns period=50.000ns})
Destination: p1750_lackn
(output port clocked by p1750_hclk_gen {rise@0.000ns fall@25.000ns period=50.000ns})
Path Group: p1750_hclk_gen
Path Type: Max at Slow Process Corner
Requirement: 25.000ns (p1750_hclk_gen rise@50.000ns - clk_out3_clk_synthesizer_1 fall@25.000ns)
Data Path Delay: 9.508ns (logic 3.445ns (36.236%) route 6.063ns (63.764%))
Logic Levels: 2 (LUT1=1 OBUF=1)
Output Delay: 18.000ns
Clock Path Skew: 6.748ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 8.597ns = ( 58.597 - 50.000 )
Source Clock Delay (SCD): 1.863ns = ( 26.863 - 25.000 )
Clock Pessimism Removal (CPR): 0.014ns
Clock Uncertainty: 0.625ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Discrete Jitter (DJ): 0.383ns
Phase Error (PE): 0.431ns

Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk_out3_clk_synthesizer_1 fall edge) 

25.000 25.000 f
BUFGCTRL_X0Y11 BUFG 0.000 25.000 f pclk_mb_to_ClockReset/O
net (fo=1, routed) 1.588 26.588 ClockReset_inst/synthesizer/inst/clk_in2
MMCME2_ADV_X0Y4 MMCME2_ADV (Prop_mmcme2_adv_CLKIN2_CLKOUT2)
-3.356 23.232 f ClockReset_inst/synthesizer/inst/mmcm_adv_inst/CLKOUT2
net (fo=1, routed) 1.650 24.882 ClockReset_inst/synthesizer/inst/clk_out3_clk_synthesizer
BUFGCTRL_X0Y16 BUFG (Prop_bufg_I_O) 0.120 25.002 f ClockReset_inst/synthesizer/inst/clkout3_buf/O
net (fo=15774, routed) 1.861 26.863 spock_emulation_inst/Bridge_inst/test_point32_OBUF
SLICE_X10Y62 FDPE r spock_emulation_inst/Bridge_inst/lack_reg/C (IS_INVERTED)
------------------------------------------------------------------- -------------------
SLICE_X10Y62 FDPE (Prop_fdpe_C_Q) 0.315 27.178 f spock_emulation_inst/Bridge_inst/lack_reg/Q
net (fo=20, routed) 0.757 27.935 spock_emulation_inst/Bridge_inst/lack_reg_0
SLICE_X28Y62 LUT1 (Prop_lut1_I0_O) 0.053 27.988 r spock_emulation_inst/Bridge_inst/p1750_lackn_OBUF_inst_i_1/O
net (fo=3, routed) 5.305 33.294 p1750_lackn_OBUF
C20 OBUF (Prop_obuf_I_O) 3.077 36.371 r p1750_lackn_OBUF_inst/O
net (fo=0) 0.000 36.371 p1750_lackn
C20 r p1750_lackn (OUT)
------------------------------------------------------------------- -------------------

(clock p1750_hclk_gen rise edge)
50.000 50.000 r
BUFGCTRL_X0Y11 BUFG 0.000 50.000 r pclk_mb_to_ClockReset/O
net (fo=1, routed) 1.453 51.453 ClockReset_inst/synthesizer/inst/clk_in2
MMCME2_ADV_X0Y4 MMCME2_ADV (Prop_mmcme2_adv_CLKIN2_CLKOUT2)
-3.131 48.322 r ClockReset_inst/synthesizer/inst/mmcm_adv_inst/CLKOUT2
net (fo=1, routed) 1.567 49.889 ClockReset_inst/synthesizer/inst/clk_out3_clk_synthesizer
BUFGCTRL_X0Y16 BUFG (Prop_bufg_I_O) 0.113 50.002 r ClockReset_inst/synthesizer/inst/clkout3_buf/O
net (fo=15774, routed) 2.048 52.050 p1750_clk_drp_inst/inst/clk_in1
MMCME2_ADV_X0Y0 MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT0)
-4.809 47.241 r p1750_clk_drp_inst/inst/mmcm_adv_inst/CLKOUT0 <<<<----
net (fo=2, routed) 2.650 49.891 p1750_clk_drp_inst/inst/clk_out1_clk_synthesizer_drp
BUFGCTRL_X0Y6 BUFGCTRL (Prop_bufgctrl_I0_O)
0.113 50.004 r p1750_clk_drp_inst/inst/clkout1_buf/O
net (fo=4, routed) 2.170 52.174 p1750_hclk_i
SLICE_X0Y73 LUT2 (Prop_lut2_I0_O) 0.042 52.216 r p1750_hclk_OBUF_inst_i_1/O
net (fo=3, routed) 3.367 55.583 p1750_hclk_OBUF
P19 OBUF (Prop_obuf_I_O) 3.014 58.597 r p1750_hclk_OBUF_inst/O
net (fo=0) 0.000 58.597 p1750_hclk
P19 r p1750_hclk (OUT)
clock pessimism 0.014 58.611
clock uncertainty -0.625 57.985
output delay -18.000 39.985
-------------------------------------------------------------------
required time 39.985
arrival time -36.371
-------------------------------------------------------------------
slack 3.615

 

Well that format is quite ugly but you can see the Line I put the <<<--- on has the delay of the MMCME2 which is only -4.809ns whereas I expected it to be closer to -11ns?  The input clock to the MMCM is 20MHz (50ns) and a -76 phase shift should have been a -11ns delay.

 

So does the timing engine take into account the Delays that are assigned to MMCM's?  If so why doesn't it show up in this report?

 

Just so you know I looked at these signal with a Scope I asked for 18ns of setup relative to this new clock and I got about 9ns.  So the report says passing but it missed the fast that the clock had a phase delay.

 

Yes this clock is created with "create_generated_clock" and maybe the source is incorrect?  Here is how I generated it:

 

create_generated_clock -name p1750_hclk_gen \
-source [get_pins ClockReset_inst/synthesizer/inst/clk_in2] \
-divide_by 1 \
[get_ports p1750_hclk]

 

So I used the input reference at the very top of the clock chain; my belief was that the tool works through the MMCMs to account for all the delays.

 

Very long post, thanks in advance for reading and considering!

TomT...

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
8,996 Views
Registered: ‎01-23-2009

Re: MMCM Phase Delay not showing up in timing Report?

Jump to solution

1) Could I use one MMCM to generate all the clocks I outlined?

 

No, I think it is one more clock than you can do. You seem to need 8 clocks, but a single MMCM can only generate 7 (CLKOUT0 to CLKOUT6).

 

That being said, you might be able to get away with using a BUFGCE for some of the more tightly related clocks - for example, don't generate a 40MHz clock, but instead use the 80MHz clock to drive a BUFG (for the 80MHz clock) and a BUFGCE - use the 80MHz clock (after the BUFG) to generate an enable that is active one clock out of every 2 and use this for the CE of the BUFGCE. This will generate a 40MHz clock that is in phase with the 80, but has a duty cycle of 25/75 (instead of 50/50). If you don't care about the falling edge, then this is a solution to get all the clocks from one MMCM.

 

Of course, I haven't tried all the different frequencies together. Use the clock wizard and it will figure out the best programming of the dividers. It may be that the inclusion of the 125MHz related clocks will force the VCO to be something "non-optimal" which will create more jitter on all the clocks...

 

Oh - wait - I forgot about CLKFBOUT... This is actually an 8th clock! By definition CLKFBOUT is the same frequency as the clock input, so you can use this for your 20MHz clock output (along with the connection to CLKFBIN). While the clocking wizard does not allow you to put logic on the CLKFBOUT BUFG, it is legal to do so (but you will have to instantiate all the clocking by hand to do this).

 

2) Is cascading 2 MMCMs to generate unrelated clocks acceptable -- I know the tools support it as I am doing that now?

 

It is probably acceptable, but it is probably better to have them in parallel, rather than in series - have the same clock input (or clock inputs) drive the CLKIN of both MMCMs - have one MMCM generate one set of outputs, and the other one the other set. When done like this (assuming both CLKIN come from the same BUFG clock and you are using BUFG feedback for both) the outputs of the two MMCMs are actually in phase - while you don't need this, it can be useful.

 

Avrum

Tags (1)
0 Kudos
9 Replies
Highlighted
Historian
Historian
5,460 Views
Registered: ‎01-23-2009

Re: MMCM Phase Delay not showing up in timing Report?

Jump to solution

So, first (and maybe even last) - you shouldn't be constraining the output of the MMCM. The correct way to use a system like this is to set a create_clock on the input of the FPGA (that feeds the input of the MMCM) and let the tools derive the appropriate constraints for the MMCM.

 

Second - in Vivado there is an important difference between a phase delay and a propagation delay. The delay of the MMCM (the -4.809) is the propagation delay of the MMCM (which happens to be negative). The phase shift of the MMCM, though is a phase delay - it manifests as a shift in the source clock edges. So instead of your clock having edges at 0, 25, and 50, it would, instead, have edges at -10.55, 14.44 and 39.44. The propagation delay through the MMCM will be unaffected by the phase shift.

 

I suspect that these two are related. By putting the create_generated_clock on the output of your MMCM, you are overriding the automatically generated clock (which has the correct edges) with one that you defined that has the edges in the same place as the source clock. This, of course, totally messes up the analysis. So remove the create_generated_clock.

 

Further, you clearly have other problems...

 

From what I can see from your timing path, the clock delays don't start at ports of the design. This means that you have a create_clock on an internal signal, which is almost never a good idea - the create_clock should almost always and only be placed on ports of the design that bring in primary clocks.

 

Next, your clock structure is a mess - you have a cascade of 3 BUFGCTRLs and 2 MMCMs! Most "reasonable" clock structures are significantly simpler - ideally a clock input, a single MMCM and a BUFGCTRL. If you need multiple related clocks, they should all be outputs of the same MMCM.

 

And lastly (as I mentioned in your other post), you should always forward a clock out through an ODDR...

 

So, again, tell us what you need to accomplish - what you are trying to interface to and what it needs in terms of timing requirements. We can help you design an appropriate clock structure - I am pretty sure this isn't it...

 

Avrum

0 Kudos
Explorer
Explorer
5,407 Views
Registered: ‎11-13-2009

Re: MMCM Phase Delay not showing up in timing Report?

Jump to solution

Avrunw,

 

You are most correct this clocking structure is a mess.  Let me give you the 5000 foot view and we should be able to resolve this fairly quickly.

 

1) I have two source clocks into the FPGA, they are both 20MHz.  There are two because we have two usage models, one where the board is plugged into the backplane and one where the board is on the bench (for initial bring-up and testing).  For my timing analysis I use "set_case_analysis" to pick only the backplane. I also set_clock_groups -physically_exclusive for these two sources.

 

2) I use this 20MHz clock to source the following clocks in my system: 10MHz, 16MHz, 20MHz, 40MHz, 80MHz, 80MHz_90degreeshift, 125MHz, 20MHz_phaseControlled; I used the names that Vivado came up with for these clocks in my constraint file.  It is possible to use two MMCMs to create these clocks as the 16MHz, 40MHz and 125MHz are unrelated to the others.  There are CDC circuits to account for the crossings.

 

3) For the 20MHz_phaseControlled I enabled a single MMCM with phase shifting using the input signals: psclk, psen, psincdec, psdone.  If I could do this on one MMCM with the other clocks it would be useful. I have used "create_generated_clock" on this output as the default Vivado selection was not naturally in the tree that I selected above -- this is a source of confusion as you pointed out.  I attached a screenshot of the Vivado Clock Summary.

 

4) The 125MHz clock is a source clock to another 2-input selector which chooses from the card edge PCIe clock or the internally generated (when board on bench) 125MHz.  I haven't seen a problem with this logic or timing analysis at this point.  Bench testing is NOT the normal operating mode for this system.

 

You are correct I have mistaken the natural MMCM delay as a portion of the phase delay.  It is entirely possible that I have somehow inadvertently overridden my intent which was to have only the source edge connector 20MHz as the primary input to all the timing analysis.  I will review and see if there is an answer there.

 

Now onto why I need to modify the Phase of the 20MHz clock leaving the chip. The external system goes through a series of level shifters to get to the final device I am interfacing to.  This device is a 25 year old processor which has a messy interface. By controlling the clock I have been able to find the sweet spot of operation.  It is as simple as that, I have discovered that because of the various level shifter and the propagation delay and the sheer number of pins necessary I had to use different FPGA voltage banks from the Kintex-7 part.

 

Finally to give you some history I originally interfaced to this processor with a VirtexII about 15 years ago; some of my methods I devised then to solve this problem.  I should have backed up and solved this using the Series-7 way!

 

Please let me know what additional information I could provide. I will look into using the ODDR as my clock output network right away.

 

Thanks,

TomT...

Screen Shot 2017-07-31 at 8.55.24 AM.png
0 Kudos
Historian
Historian
5,399 Views
Registered: ‎01-23-2009

Re: MMCM Phase Delay not showing up in timing Report?

Jump to solution

1) I have two source clocks into the FPGA, they are both 20MHz.

 

Ideally the two sources should be on clock capable inputs in the same clock region and should use the CLKIN1 and CLKIN2 of the same MMCM. This internal MUX is much faster than using a BUFGMUX.

 

I used the names that Vivado came up with for these clocks in my constraint file.

 

You can rename clocks if you want using the create_generated_clock command, without specifying a source or a relationship - see this post on renaming clocks.

 

If I could do this on one MMCM with the other clocks it would be useful.

 

The programmable shift is selectable on a clock by clock basis. While there is only one shifter, each output can individually choose to use the shifted clock or the unshifted clock. This is selected by the CLKOUTx_USE_FINE_PS - if you set this to true for one output it will use the shifter - if you set it to false, it will use the unshifted clock. The parameter is also settable from the clock wizard (USE_PS).

 

as the default Vivado selection was not naturally in the tree that I selected above

 

The "tree" shown in the clock summary only tells how the clocks are generated - it doesn't have any effect on which clocks are "related" to eachother - In Vivado, all clocks are related by default. So whether this clock showed up in the same part of the clock summary tree or not doesn't matter.

 

Everything I have heard so far says that the only constraint you need is the create_clock on the two 20MHz inputs and the set_clock_groups -mutually_exclusive on the two 20MHz inputs (or even a set_case_analysis) - the tools should be able to manage everything else.

 

Avrum

 

 

0 Kudos
Explorer
Explorer
5,387 Views
Registered: ‎11-13-2009

Re: MMCM Phase Delay not showing up in timing Report?

Jump to solution

Avrumw,

 

I think the hint you gave me that I was unsure of was the use of the create_clock or create_generated_clock to rename an existing clock.  I will give that a try so I don't have to rip up my entire XDC file with new names; yes cut/paste but error prone none the less.  I am going to remove any create_clock/create_generated_clock from my scripts other than the original input pins and see what happens.

 

So your second concern about clock pins has me a little concerned but there is nothing I can do about it now, the production boards are being built and an ECO in this area is not in our future.  I do use the on-board Oscillator directly as a clock for a couple pieces of startup logic.  I believe that would most likely invalidate the normal usage you mentioned in your post.  For now have have hand instantiated a BUFG from the port_names.  It is those outputs of the BUFG which feed the MMCM inputs of clk1 and clk2.

 

Your answer to if I could use one MMCM was incomplete because what I couldn't tell is if I have enough clock resources in one MMCM for this effort.  I do understand that I could generate two 20MHz clocks with one being modified by the "USE_FINE_PS" switch and the others wouldn't be affected.  My suggestion is to generate all the 20MHz related signals in one MMCM and then cascade to a second to generate the 125MHz, 16MHz and 40MHz which are not related to the 20MHz nor to each other.

 

You have given me some useful things to think about.  I did already add the ODDR for the clock drive output and it RTL simulates exactly like the one with the clock driving the pin, thanks for the hint about that as a more stable solution.  Funny I have used this approach for source-sync interface based design in the past; just totally forgot about it.

 

So I think the questions are:

1) Could I use one MMCM to generate all the clocks I outlined?

2) Is cascading 2 MMCMs to generate unrelated clocks acceptable -- I know the tools support it as I am doing that now?

 

Thanks in advance and as always you are are spot on your answers.

TomT...

 

 

 

 

0 Kudos
Newbie kbork
Newbie
5,380 Views
Registered: ‎07-31-2017

Re: MMCM Phase Delay not showing up in timing Report?

Jump to solution

I do not mean to hijack this issue, but I am having exactly the same problem as was briefly mentioned and then passed by (and is the subject of the post).  The comment was:

 

"Second - in Vivado there is an important difference between a phase delay and a propagation delay. The delay of the MMCM (the -4.809) is the propagation delay of the MMCM (which happens to be negative). The phase shift of the MMCM, though is a phase delay - it manifests as a shift in the source clock edges. So instead of your clock having edges at 0, 25, and 50, it would, instead, have edges at -10.55, 14.44 and 39.44. The propagation delay through the MMCM will be unaffected by the phase shift."

 

OK, I get that.

 

However, I am a literalist.  Showing a timing report that shifts the clock edges at the inputs now violates my constraints that say my clock and data at the I/O of the FPGA have a certain relationship.  The shift in clock edges makes it appear like they arrive at the FPGA offset from when they really arrive.  The phase shift happens in the MMCM.  So, why does the MMCM output NOT show the phase shift relative to the input of the MMCM?  Or at least the phase shift should happen within the clock delay path, not before it gets to the FPGA.

 

Is the answer... "It just IS"?

I'm having a hard time believing the timing report, since the phase shift is not where I expect to see it.

 

Thanks, Kristine

0 Kudos
Historian
Historian
8,997 Views
Registered: ‎01-23-2009

Re: MMCM Phase Delay not showing up in timing Report?

Jump to solution

1) Could I use one MMCM to generate all the clocks I outlined?

 

No, I think it is one more clock than you can do. You seem to need 8 clocks, but a single MMCM can only generate 7 (CLKOUT0 to CLKOUT6).

 

That being said, you might be able to get away with using a BUFGCE for some of the more tightly related clocks - for example, don't generate a 40MHz clock, but instead use the 80MHz clock to drive a BUFG (for the 80MHz clock) and a BUFGCE - use the 80MHz clock (after the BUFG) to generate an enable that is active one clock out of every 2 and use this for the CE of the BUFGCE. This will generate a 40MHz clock that is in phase with the 80, but has a duty cycle of 25/75 (instead of 50/50). If you don't care about the falling edge, then this is a solution to get all the clocks from one MMCM.

 

Of course, I haven't tried all the different frequencies together. Use the clock wizard and it will figure out the best programming of the dividers. It may be that the inclusion of the 125MHz related clocks will force the VCO to be something "non-optimal" which will create more jitter on all the clocks...

 

Oh - wait - I forgot about CLKFBOUT... This is actually an 8th clock! By definition CLKFBOUT is the same frequency as the clock input, so you can use this for your 20MHz clock output (along with the connection to CLKFBIN). While the clocking wizard does not allow you to put logic on the CLKFBOUT BUFG, it is legal to do so (but you will have to instantiate all the clocking by hand to do this).

 

2) Is cascading 2 MMCMs to generate unrelated clocks acceptable -- I know the tools support it as I am doing that now?

 

It is probably acceptable, but it is probably better to have them in parallel, rather than in series - have the same clock input (or clock inputs) drive the CLKIN of both MMCMs - have one MMCM generate one set of outputs, and the other one the other set. When done like this (assuming both CLKIN come from the same BUFG clock and you are using BUFG feedback for both) the outputs of the two MMCMs are actually in phase - while you don't need this, it can be useful.

 

Avrum

Tags (1)
0 Kudos
Historian
Historian
5,372 Views
Registered: ‎01-23-2009

Re: MMCM Phase Delay not showing up in timing Report?

Jump to solution

Is the answer... "It just IS"?

 

Unfortunately, the answer is "it just is".

 

You are right - in the timing report, it shows the arrival of the clock at the pin phase shifted in time - in spite of the fact that the phase shift itself actually occurs in the MMCM, which is downstream from the pin. So it looks wrong, since there is no clock edge at the pin at -10.55ns.

 

But this is part of the (very important) mechanism that the tools use to figure out the edge relationship for determining launch and capture edges. It may be "odd", but it does work, and it fits in with all the rest of the timing analysis stuff done by Vivado (and other SDC based STA tools).

 

Avrum

Tags (3)
0 Kudos
Contributor
Contributor
5,177 Views
Registered: ‎03-13-2017

Re: MMCM Phase Delay not showing up in timing Report?

Jump to solution

 

It seems like there is an alternative to "it just is" that I have not seen it mentioned here.

 

MMCM/PLL have a "PHASESHIFT_MODE" property that can be set to "LATENCY". This causes timing analysis to handle clock phase shift by adjusting the latency of the MMCM/PLL. The other option, PHASESHIFT_MODE=WAVEFORM, is the behavior that @avrumw described. This is described in UG906 Chapter 5.

 

Of course, if you have already written your constraints assuming PHASESHIFT_MODE=WAVEFORM, you may have to change them when you switch to PHASESHIFT_MODE=LATENCY since the launch and capture edges could change.

Historian
Historian
5,172 Views
Registered: ‎01-23-2009

Re: MMCM Phase Delay not showing up in timing Report?

Jump to solution

(Ummm - yikes!)

 

@rjbohnert,

 

Thanks for pointing this out. This feature is new to 2016.3, and (presumably) was added for UltraScale+. It is important to note that the default is WAVEFORM for the 7-series and UltraScale and LATENCY for UltraScale+.

 

I am looking into this internally - for now, I would advise people not to consider using LATENCY mode for the MMCM. If I understand it correctly, this has the potential to have significant (and not immediately obvious) impact on designs...

 

I will follow up when I get more information!

 

Avrum

 

Tags (1)
0 Kudos