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: 
1,674 Views
Registered: ‎10-07-2018

Undesirable Phase shifts between two similar MMCMs

Jump to solution

We have instantiated 2 MMCMs which can be dynamically configured using DRP(xapp888) with CLKOUT4_CASCADE = "TRUE". Input clock to both the MMCMs is 125MHz from oscillator. Both have same settings except that one MMCM has dynamically configurable phase. To generate this variable phase , we are using Delay Time register ( Setting the register in one MMCM to desirable count and the other to 0). We are observing that the phases of both the MMCM outputs are randomly changing with every reconfiguration. Is this supposed to happen this way or are we missing anything ?? 

 

P.S. Even during the start up , before any reconfiguration, the outputs are out of phase.

 

BUFG BUFG_FB_1 (
   .O(clkfb_bufgout_mm1),
   .I(clkfb_bufgin_mm1) 
);

BUFG BUFG_FB_2 (
   .O(clkfb_bufgout_mm2),
   .I(clkfb_bufgin_mm2) 
);

MMCME2_ADV #(
  // "HIGH", "LOW" or "OPTIMIZED"
  .BANDWIDTH("OPTIMIZED"), 
  .DIVCLK_DIVIDE(5), // (1 to 106)
                        //                   Calculations
  .CLKFBOUT_MULT_F(44), // (2 to 64)    VC0 = 1100 = 125 * 44 / 5
  .CLKFBOUT_PHASE(0.0),
  .CLKFBOUT_USE_FINE_PS("FALSE"),

  // Set the clock period (ns) of input clocks
  .CLKIN1_PERIOD(8.000), 
  .REF_JITTER1(0.010),
  
  .CLKIN2_PERIOD(10.000),
  .REF_JITTER2(0.010),

  // CLKOUT parameters:
  // DIVIDE: (1 to 128)
  // DUTY_CYCLE: (0.01 to 0.99) - This is dependent on the divide value.
  // PHASE: (0.0 to 360.0) - This is dependent on the divide value.
  // USE_FINE_PS: (TRUE or FALSE)
    
  .CLKOUT0_DIVIDE_F(1),    
  .CLKOUT0_DUTY_CYCLE(0.5), 
  .CLKOUT0_PHASE(0.0), 
  .CLKOUT0_USE_FINE_PS("FALSE"),

  .CLKOUT1_DIVIDE(1),      
  .CLKOUT1_DUTY_CYCLE(0.5), 
  .CLKOUT1_PHASE(0.0),
  .CLKOUT1_USE_FINE_PS("FALSE"),    

  .CLKOUT2_DIVIDE(1), 
  .CLKOUT2_DUTY_CYCLE(0.5), 
  .CLKOUT2_PHASE(0.0), 
  .CLKOUT2_USE_FINE_PS("FALSE"),

  .CLKOUT3_DIVIDE(1), 
  .CLKOUT3_DUTY_CYCLE(0.5), 
  .CLKOUT3_PHASE(0.0), 
  .CLKOUT3_USE_FINE_PS("FALSE"),

  .CLKOUT4_DIVIDE(5), 
  .CLKOUT4_DUTY_CYCLE(0.5), 
  .CLKOUT4_PHASE(0.0), 
  .CLKOUT4_USE_FINE_PS("FALSE"),
  .CLKOUT4_CASCADE("TRUE"),

  .CLKOUT5_DIVIDE(1), 
  .CLKOUT5_DUTY_CYCLE(0.5), 
  .CLKOUT5_PHASE(0.0),
  .CLKOUT5_USE_FINE_PS("FALSE"),      
  
  .CLKOUT6_DIVIDE(5), 
  .CLKOUT6_DUTY_CYCLE(0.5), 
  .CLKOUT6_PHASE(0.0), 
  .CLKOUT6_USE_FINE_PS("FALSE"),
  
  // Misc parameters
  .COMPENSATION("ZHOLD"),
  .STARTUP_WAIT("FALSE")
) mmcme2_fxd_phase (
  .CLKFBOUT(clkfb_bufgin_mm1),
  .CLKFBOUTB(),
  
  .CLKFBSTOPPED(),
  .CLKINSTOPPED(),

  // Clock outputs
  .CLKOUT0(), 
  .CLKOUT0B(),
  .CLKOUT1(),
  .CLKOUT1B(),
  .CLKOUT2(),
  .CLKOUT2B(),
  .CLKOUT3(),
  .CLKOUT3B(),
  .CLKOUT4(w_clk_fxd_bufg_in), 
  .CLKOUT5(), 
  .CLKOUT6(),

  // DRP Ports
  .DO    (o_DOUT), // (16-bits)
  .DRDY  (w_drdy_mm1), 
  .DADDR (i_DADDR), // 7 bits
  .DCLK  (i_sys_clk), 
  .DEN   (i_DEN), 
  .DI    (i_DI_MM1), // 16 bits
  .DWE   (i_DWE), 

  .LOCKED (w_locked_mm1), 
  .CLKFBIN(clkfb_bufgout_mm1), 

  // Clock inputs
  .CLKIN1  (CLKIN_ibuf),
  .CLKIN2  (),
  .CLKINSEL(1'b1), 

  // Fine phase shifting
  .PSDONE  (),
  .PSCLK   (1'b0),
  .PSEN    (1'b0),
  .PSINCDEC(1'b0),

  .PWRDWN(1'b0),
  .RST   (i_RST_MMCM)
);

MMCME2_ADV #(
  // "HIGH", "LOW" or "OPTIMIZED"
  .BANDWIDTH("OPTIMIZED"), 
  .DIVCLK_DIVIDE(5), // (1 to 106)
                        //                   Calculations
  .CLKFBOUT_MULT_F(44), // (2 to 64)    VC0 = 1100 = 125 * 44 / 5
  .CLKFBOUT_PHASE(0.0),
  .CLKFBOUT_USE_FINE_PS("FALSE"),

  // Set the clock period (ns) of input clocks
  .CLKIN1_PERIOD(8.000), 
  .REF_JITTER1(0.010),
  
  .CLKIN2_PERIOD(10.000),
  .REF_JITTER2(0.010),

  // CLKOUT parameters:
  // DIVIDE: (1 to 128)
  // DUTY_CYCLE: (0.01 to 0.99) - This is dependent on the divide value.
  // PHASE: (0.0 to 360.0) - This is dependent on the divide value.
  // USE_FINE_PS: (TRUE or FALSE)
    
  .CLKOUT0_DIVIDE_F(1),    
  .CLKOUT0_DUTY_CYCLE(0.5), 
  .CLKOUT0_PHASE(0.0), 
  .CLKOUT0_USE_FINE_PS("FALSE"),

  .CLKOUT1_DIVIDE(1),      
  .CLKOUT1_DUTY_CYCLE(0.5), 
  .CLKOUT1_PHASE(0.0),
  .CLKOUT1_USE_FINE_PS("FALSE"),    

  .CLKOUT2_DIVIDE(1), 
  .CLKOUT2_DUTY_CYCLE(0.5), 
  .CLKOUT2_PHASE(0.0), 
  .CLKOUT2_USE_FINE_PS("FALSE"),

  .CLKOUT3_DIVIDE(1), 
  .CLKOUT3_DUTY_CYCLE(0.5), 
  .CLKOUT3_PHASE(0.0), 
  .CLKOUT3_USE_FINE_PS("FALSE"),

  .CLKOUT4_DIVIDE(5), 
  .CLKOUT4_DUTY_CYCLE(0.5), 
  .CLKOUT4_PHASE(0.0), 
  .CLKOUT4_USE_FINE_PS("FALSE"),
  .CLKOUT4_CASCADE("TRUE"),

  .CLKOUT5_DIVIDE(1), 
  .CLKOUT5_DUTY_CYCLE(0.5), 
  .CLKOUT5_PHASE(0.0),
  .CLKOUT5_USE_FINE_PS("FALSE"),      
  
  .CLKOUT6_DIVIDE(5), 
  .CLKOUT6_DUTY_CYCLE(0.5), 
  .CLKOUT6_PHASE(0.0), 
  .CLKOUT6_USE_FINE_PS("FALSE"),
  
  // Misc parameters
  .COMPENSATION("ZHOLD"),
  .STARTUP_WAIT("FALSE")
) mmcme2_var_phase (
  .CLKFBOUT(clkfb_bufgin_mm2),
  .CLKFBOUTB(),
  
  .CLKFBSTOPPED(),
  .CLKINSTOPPED(),

  // Clock outputs
  .CLKOUT0(), 
  .CLKOUT0B(),
  .CLKOUT1(),
  .CLKOUT1B(),
  .CLKOUT2(),
  .CLKOUT2B(),
  .CLKOUT3(),
  .CLKOUT3B(),
  .CLKOUT4(w_clk_var_bufg_in), 
  .CLKOUT5(), 
  .CLKOUT6(),

  // DRP Ports
  .DO    (w_DOUT), // (16-bits)
  .DRDY  (w_drdy_mm2), 
  .DADDR (i_DADDR), // 7 bits
  .DCLK  (i_sys_clk), 
 
  .DEN   (i_DEN), 
  .DI    (i_DI_MM2), // 16 bits
  .DWE   (i_DWE), 

  .LOCKED (w_locked_mm2), 
  .CLKFBIN(clkfb_bufgout_mm2), 

  // Clock inputs
  .CLKIN1  (CLKIN_ibuf),
  .CLKIN2  (),
  .CLKINSEL(1'b1), 

  // Fine phase shifting
  .PSDONE  (),
  .PSCLK   (1'b0),
  .PSEN    (1'b0),
  .PSINCDEC(1'b0),

  .PWRDWN(1'b0),
  .RST   (i_RST_MMCM)
);

BUFG bufg_var_clk ( 
    .O (o_rffe_clk_var),   // 1-bit output: Clock buffer output
    .I (w_clk_var_bufg_in)  // 1-bit input: Clock buffer input
);


BUFG bufg_fxd_clk ( 
    .O (o_rffe_clk_fxd),   // 1-bit output: Clock buffer output
    .I (w_clk_fxd_bufg_in)  // 1-bit input: Clock buffer input
);
Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
1,374 Views
Registered: ‎01-23-2009

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

Let's look at how an MMCM works. First, let's focus only on the VCO.

image.png

The PFD, CP and LF make sure that the VCO produces a clock that results in the CLKFBIN input of the MMCM being in phase with the CLKIN/D input (usually D is one). So the VCO is running at Fin*M, and is guaranteed to be in phase.

All the O outputs are then counters based on the VCO frequency. Once lock is achieved, all the O counters are reset so that they all start "in phase" - this guarantees that two clocks with a frequency that are multiples of each other stay in phase. For example if CLKIN=100MHz, and you have CLKOUT0=100MHz and CLKOUT1=200MHz, this reset is required, since the VCO would be running faster (say at 1000MHz) so the DIVIDE0=10 and DIVIDE1=5 - without a reset, the rising edge of CLKOUT0 may be shifted from CLKOUT1 in any increment of 1ns (due to the VCO running at 1000MHz).

It is, in fact, because of this that the outputs of different MMCMs are not in phase. If two MMCMs get the same 100MHz clock, then the PFD, CP, and LF will ensure that the VCO is running at the same frequency and phase in the two MMCMs. However, there is no mechanism to ensure that the O counters in the two MMCMs are reset at the same time, which can result in them having a phase difference in increments of one VCO period.

[EDIT:

This is only partly correct. We know that for any MMCM, CLKFBOUT and CLKIN are in phase - the PFD guarantees that. Therefore the count value of the M divider is guaranteed to be synchronized with the input clock. Since we know that all dividers (the Ox dividers) are in phase with the M divider, then there is some guarantee of phase between different MMCMs.

Where you can get out of phase is when the frequency one of your O clocks is a non integer multiple of the input clock - this includes any division. For exaple if Fin=100MHz then CLKFBOUT is also 100MHz (assuming D=1). So any clock that is n*100MHz will be of "known phase", and will be the same in two MMCMs that use the same CLKIN.

However, if one of the outputs is (say) 50MHz, then there are two possible phases for that 50MHz - it is this that is non-deterministic between two MMCMs that use the same CLKIN.

So it isn't true that they can be out of phase by any multiple of the VCO period - its more complicated than that...

]

Furthermore, the datasheet states that all outputs are phase aligned to within MMCM_Tstatphaoffset, which is 120ps, and the static timing tools take this into account. This of course assumes that the programmed phase of the outputs is 0. If you program a phase offset (either a static phase offset, or a fine phase shift offset or a dynamic offset - all of these including an offset in the CLKFBOUT path), then the phase offset will be the specified offset +/-MMCM_Tstatphaoffset.

So that covers all "normal outputs". However, there is some indication that CLKOUT4 when using the CLKOUT4_CASCADE does not follow this. In the Clocking user guide (UG472, v1.14, p.76, "MMCM Counter Cascading") it states "There is a static phase offset between the output of the cascaded divider and all other dividers". This implies that the offset is more than MMCM_Tstatphaoffset, but it gives us no indication as to what it is.

I would assume the tools would know, though. It should be easy to mock up a system with an MMCM with 3 outputs CLKOUT0, CLKOUT1 and CLKOUT4 where CLKOUT_4 uses a cascade. Then create paths between combinations of the clocks. Between 0 and 1 you should see MMCM_Tstatphaoffset in the timing budget (it won't be called this, but it should be pretty obvious - maybe in the clock uncertainty). Between CLKOUT4 and the others, you should see a different value for this. You can even see the difference between them in setup and hold checks and at slow and fast timing corners (if you ask report_timing nicely).

If the additional skew for the CLKOUT4_CASCADE is on the order of another 100ps or so, then you can probably still consider them as synchronous domains - you will have more timing problems (including hold times that need to be fixed) between them, but if the skew is still reasonable, then the tools should fix them. If the additional skew is more like 0.5ns, then this is probably not an option, and you will have to consider this clock as mesochronous to the other clocks (or at least find more "clever" ways of crossing between the domains).

Avrum

Tags (1)
11 Replies
1,604 Views
Registered: ‎01-22-2015

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

@sudarshan.shenoy

     ....except that one MMCM has dynamically configurable phase..
XAPP888 says “The design does not support outputs configured with fine-phase shifting enabled”. That is, since XAPP888 methods do not allow you to enable CLKOUT[0:6]_USE_FINE_PS and CLKFBOUT_USE_FINE_PS, you should not be able to use XAPP888 methods to do dynamic phase shifting for the MMCM.   Some seem to have found a workaround as explained <here> . I have not tested this workaround.

However, the MMCME2_ADV primitive allows you to do dynamic phase shifting. This is described on about page 75 in the section of UG472 called Dynamic Phase Shift Interface in the MMCM.  The MMCME2_ADV primitive is described on about page 419 of UG953.

     ...phases of both the MMCM outputs are randomly changing with every reconfiguration.
Note from UG472 that after the MMCM locks, the initial phase is determined by the CLKOUT_PHASE attribute.

Cheers,
Mark

0 Kudos
1,580 Views
Registered: ‎10-07-2018

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

markg@prosensing.com Yes, we are not using fine-phase shifting. To achieve this Phase shift we are using the Delay Time register in CLKOUT Register 2.

 

Initially CLKOUT_PHASE of both the MMCM outputs are 0 (see code). Still the outputs of the two MMCMs are out of phase. 

Is it right to use both CLKOUT4_CASCADE and Delay time register in a single reconfiguration as we have done ?

0 Kudos
1,538 Views
Registered: ‎01-22-2015

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

@sudarshan.shenoy

     Is it right to use both CLKOUT4_CASCADE and Delay time register in a single reconfiguration as we have done ?
My reading and experience cannot provide an answer for you. I am sorry.

     Still the outputs of the two MMCMs are out of phase.
At power-up, I don’t think we can expect output clocks from one MMCM to be in-phase with output clocks from another MMCM (even though the two MMCM’s have a common input clock). I suspect that an alignment procedure is needed (especially since the MMCM is dividing-down the input clock) – although I cannot find mention of this in the Xilinx documentation. However, when BUFRs in adjacent clocking regions are used to divide-down a clock, a reset is needed to align their outputs (see “BUFR Alignment” in Appendix A of UG472). So, after power-up, perhaps you need to simultaneous reset both MMCMs to align their outputs ?

How are you measuring the phase-shift between the outputs of the two MMCMs?

Mark

0 Kudos
1,502 Views
Registered: ‎10-07-2018

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution


markg@prosensing.com

How are you measuring the phase-shift between the outputs of the two MMCMs?

We are observing the clocks in an Oscillscope at a sampling rate of 1G/s. 


So, after power-up, perhaps you need to simultaneous reset both MMCMs to align their outputs ?

Yes we have tried this. For the MMCMs, even if the resets are simultaneous, the lock signals vary ( and so does the phase between them).

0 Kudos
1,479 Views
Registered: ‎01-22-2015

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

@sudarshan.shenoy

     We are observing the clocks in an Oscillscope at a sampling rate of 1G/s.
Also, be sure to route clocks out of the FPGA using the ODDR as shown in Fig 3-7 in UG903.

     For the MMCMs, even if the resets are simultaneous, the lock signals vary..
Aha – I see the problem.  Here is another idea that you can try.  Cascade two MMCMs as shown in Fig 3-16 of UG472.  The first MMCM receives the clock, CLK0, from the clock-capable pins on the FPGA and forwards a clock with the same frequency as CLK0 to the second MMCM.  Then, the clock outputs of both MMCM will be aligned (regardless of how they power-up) except for some uncompensated delay between the MMCMs as shown in Fig 3-16.  I suspect the uncompensated delay will result in small phase errors for your application because you are using slow clocks.  You should be able to use CLKOUT4_CASCADE on both MMCMs (to generate your slow clocks) and you should be able to use the “Delay Time register” method to phase shift the clock output of the second MMCM relative to the clock output of the first MMCM.
MMCM_cascade.jpg

0 Kudos
1,452 Views
Registered: ‎10-07-2018

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

Also, be sure to route clocks out of the FPGA using the ODDR as shown in Fig 3-7 in UG903.

Yes, clock forwarding. We have used the ODDRs as shown.

I suspect the uncompensated delay will result in small phase errors for your application because you are using slow clocks.  You should be able to use CLKOUT4_CASCADE on both MMCMs (to generate your slow clocks) and you should be able to use the “Delay Time register” method to phase shift the clock output of the second MMCM relative to the clock output of the first MMCM.

Will try this in the hardware and let you know. 

markg@prosensing.com We have tested something today and may have understood what the problem is. The CLKOUT6 outputs of both MMCMs are in phase even after the DRP. Even the CLKOUT4 output are in phase only when Cascade is not enabbled. When Cascade is enabled, the CLKOUT4 outputs are out of phase with each other. This is mostly due to the Cascading. The phase difference is multiple of CLKOUT6 periods. 

Even when CLKOUT4_CASCADE is "TRUE" , all outputs of both MMCMs are in phase except for the CLKOUT4.

These are the tests we did: VCO = 1000 MHz

Test 1 : Cascade off , CLKOUT4 divide = 8 and CLKOUT6 divide = 8 , Delay time = 0

Both CLKOUT4 and CLKOUT6 of MMCM1 in phase. 

Both CLKOUT4 and CLKOUT6 of MMCM2 in phase.

Both CLKOUT4 outputs of MMCM1 and MMCM2 are in phase.

Both CLKOUT6 outputs of MMCM1 and MMCM2 are in phase.

Test 2 : Cascade off , CLKOUT4 divide = 8 and CLKOUT6 divide = 8 ,CLKOUT4 Delay time = 4 (4 * VCO period = 4ns)

Both CLKOUT4 and CLKOUT6 of MMCM1 out of phase by 4ns. 

Both CLKOUT4 and CLKOUT6 of MMCM2 out of phase by 4ns.

Both CLKOUT4 outputs of MMCM1 and MMCM2 are in phase.

Both CLKOUT6 outputs of MMCM1 and MMCM2 are in phase.

Test 3 : Cascade on , CLKOUT4 divide = 8 and CLKOUT6 divide = 8 ,CLKOUT4 Delay time = 0 

Both CLKOUT4 and CLKOUT6 of MMCM1 are in phase. CLKOUT6 = 125MHz , CLKOUT4 = 15.625MHz

Both CLKOUT4 and CLKOUT6 of MMCM2 are in phase. CLKOUT6 = 125MHz , CLKOUT4 = 15.625MHz

Both CLKOUT4 outputs of MMCM1 and MMCM2 are out of phase. (Different different phase offsets for every reconfiguration; Multiples of 8ns in this case. )

Both CLKOUT6 outputs of MMCM1 and MMCM2 are in phase.

1,431 Views
Registered: ‎01-22-2015

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

@sudarshan.shenoy

Thanks very much for sharing your test results!

I look forward to your test results for the “cascaded MMCM” design.

If “cascaded MMCM” does not work then here is another design to try. Do not use CLKOUT4_CASCADE method to create your slow clocks.  Instead, create each slow clock using the method described <here> by Avrum, where a fabric-counter is used to toggle the CE pin of a BUFGCE.  At power-up of the FPGA (and after MMCMs are locked) you will need to simultaneously reset the fabric-counters for the two slow clocks.  Note that slow clocks created this way will not have 50% duty cycle.  If you need 50% duty cycle then we can talk about methods for achieving this.

Mark

 

1,406 Views
Registered: ‎10-07-2018

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

markg@prosensing.com

Thanks a lot for all your help. The "cascaded MMCM" design has same results unfortunately, the problem is with the CLKOUT4_CASCADE. But we have some idea how to make all of this work. 


Note that slow clocks created this way will not have 50% duty cycle.  If you need 50% duty cycle then we can talk about methods for achieving this.

This is not an issue. Will look into this.

0 Kudos
Highlighted
Historian
Historian
1,375 Views
Registered: ‎01-23-2009

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

Let's look at how an MMCM works. First, let's focus only on the VCO.

image.png

The PFD, CP and LF make sure that the VCO produces a clock that results in the CLKFBIN input of the MMCM being in phase with the CLKIN/D input (usually D is one). So the VCO is running at Fin*M, and is guaranteed to be in phase.

All the O outputs are then counters based on the VCO frequency. Once lock is achieved, all the O counters are reset so that they all start "in phase" - this guarantees that two clocks with a frequency that are multiples of each other stay in phase. For example if CLKIN=100MHz, and you have CLKOUT0=100MHz and CLKOUT1=200MHz, this reset is required, since the VCO would be running faster (say at 1000MHz) so the DIVIDE0=10 and DIVIDE1=5 - without a reset, the rising edge of CLKOUT0 may be shifted from CLKOUT1 in any increment of 1ns (due to the VCO running at 1000MHz).

It is, in fact, because of this that the outputs of different MMCMs are not in phase. If two MMCMs get the same 100MHz clock, then the PFD, CP, and LF will ensure that the VCO is running at the same frequency and phase in the two MMCMs. However, there is no mechanism to ensure that the O counters in the two MMCMs are reset at the same time, which can result in them having a phase difference in increments of one VCO period.

[EDIT:

This is only partly correct. We know that for any MMCM, CLKFBOUT and CLKIN are in phase - the PFD guarantees that. Therefore the count value of the M divider is guaranteed to be synchronized with the input clock. Since we know that all dividers (the Ox dividers) are in phase with the M divider, then there is some guarantee of phase between different MMCMs.

Where you can get out of phase is when the frequency one of your O clocks is a non integer multiple of the input clock - this includes any division. For exaple if Fin=100MHz then CLKFBOUT is also 100MHz (assuming D=1). So any clock that is n*100MHz will be of "known phase", and will be the same in two MMCMs that use the same CLKIN.

However, if one of the outputs is (say) 50MHz, then there are two possible phases for that 50MHz - it is this that is non-deterministic between two MMCMs that use the same CLKIN.

So it isn't true that they can be out of phase by any multiple of the VCO period - its more complicated than that...

]

Furthermore, the datasheet states that all outputs are phase aligned to within MMCM_Tstatphaoffset, which is 120ps, and the static timing tools take this into account. This of course assumes that the programmed phase of the outputs is 0. If you program a phase offset (either a static phase offset, or a fine phase shift offset or a dynamic offset - all of these including an offset in the CLKFBOUT path), then the phase offset will be the specified offset +/-MMCM_Tstatphaoffset.

So that covers all "normal outputs". However, there is some indication that CLKOUT4 when using the CLKOUT4_CASCADE does not follow this. In the Clocking user guide (UG472, v1.14, p.76, "MMCM Counter Cascading") it states "There is a static phase offset between the output of the cascaded divider and all other dividers". This implies that the offset is more than MMCM_Tstatphaoffset, but it gives us no indication as to what it is.

I would assume the tools would know, though. It should be easy to mock up a system with an MMCM with 3 outputs CLKOUT0, CLKOUT1 and CLKOUT4 where CLKOUT_4 uses a cascade. Then create paths between combinations of the clocks. Between 0 and 1 you should see MMCM_Tstatphaoffset in the timing budget (it won't be called this, but it should be pretty obvious - maybe in the clock uncertainty). Between CLKOUT4 and the others, you should see a different value for this. You can even see the difference between them in setup and hold checks and at slow and fast timing corners (if you ask report_timing nicely).

If the additional skew for the CLKOUT4_CASCADE is on the order of another 100ps or so, then you can probably still consider them as synchronous domains - you will have more timing problems (including hold times that need to be fixed) between them, but if the skew is still reasonable, then the tools should fix them. If the additional skew is more like 0.5ns, then this is probably not an option, and you will have to consider this clock as mesochronous to the other clocks (or at least find more "clever" ways of crossing between the domains).

Avrum

Tags (1)
698 Views
Registered: ‎01-22-2015

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

@avrumw 

If two MMCMs get the same 100MHz clock … there is no mechanism to ensure that the O counters in the two MMCMs are reset at the same time, which can result in them having a phase difference in increments of one VCO period.

Because of this, should we consider clock outputs of the two MMCM to be mesochronous?

The Clocking Wizard setup for an MMCM allows us to select the “Phase Alignment” feature, which apparently causes MMCM clock outputs to have a known phase relationship with the clock input. 

Is this “Phase Alignment” feature a way to overcome the fact that O counters of two MMCM are not reset at the same time?   If yes, does MMCM "Phase Alignment" allow us to correctly consider clock outputs of the two MMCM to be synchronous?

Thank you,
Mark

0 Kudos
679 Views
Registered: ‎01-22-2015

Re: Undesirable Phase shifts between two similar MMCMs

Jump to solution

@avrumw 

Indirectly, I tried to investigate this using v2018.3 Vivado and the circuit shown below (clock input and output of each MMCM is 100MHz w/no-phase-shift requested).  I suspected Vivado would complain about the clock-crossing between the two registers, SIG1_reg and OUT1_reg, if it thought that the clock outputs of the two MMCM where not synchronous.
two_mmcm.jpg

However, whether of not I used “Phase Alignment” for the MMCMs, I got the same result:  no timing errors, no complaints from report_cdc (all paths safely timed), and no complaints from report_clock_interaction (all green).