cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
505 Views
Registered: ‎01-17-2018

Timing Constraint for phase shifted mmcm output

Jump to solution

Hi Team,

I am using KCU105 Evaluation board, I generated mmcm with following configurations:

input clk=125MHz

Output clock0 = 750MHz

Output clock1 = 750MHz with  90degrees phase shift

Output clock2 = 187.5 M

Output clock3 = 375M

 

So, what constraints i need to provide for both Output clock0 & Output clock1?

 

I am providing the constraints as : 

create_generated_clock -name hs_clk -source [get_pins U_mmcm_90M_120M/inst/mmcme3_adv_inst/CLKIN1] -multiply_by 6 -divide_by 1 [get_pins {U_mmcm_90M_120M/inst/mmcme3_adv_inst/CLKOUT0}]
create_generated_clock -name hs_90_clk -source [get_pins U_mmcm_90M_120M/inst/mmcme3_adv_inst/CLKIN1] -multiply_by 6 -divide_by 1 [get_pins {U_mmcm_90M_120M/inst/mmcme3_adv_inst/CLKOUT1}]

 

 

Thank you

Krishnachaitanya

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
407 Views
Registered: ‎11-04-2010

Re: Timing Constraint for phase shifted mmcm output

Jump to solution

Hi, @ssampath ,

With the input clock of the MMCM, the tool will generate the output clock of the MMCM, and all the phase shift of the clock will be considered automatically.

The naming of the outout clock will not include the phase shift information automatically, you have to rename the output clock manually as you need. (Search rename in UG903).

You don't need to take any extra care for this phaseshift clock if all the analyzed paths are in the fabric of FPGA.

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

0 Kudos
7 Replies
Highlighted
Moderator
Moderator
465 Views
Registered: ‎04-18-2011

Re: Timing Constraint for phase shifted mmcm output

Jump to solution

If the input clock comes from a primary clock it should propagate on the outputs of the mmcm.

I would try to do create_clock on the I put clock then do nothing else and do report clocks after synthesis or link design

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Highlighted
Voyager
Voyager
418 Views
Registered: ‎10-12-2016

Re: Timing Constraint for phase shifted mmcm output

Jump to solution
Hi @klumsde, Yes, you are correct, but here clk0 and clk1 are of same frequency but clk1 is with 90 phase shift. Our main intention to post this is for timing analysis purpose. Yes, we declared input frequecy properly from the port. should we mention any phaseshit related options in MMCM output clock1 while renaming the generated output clocks or will tool considered it automatically ? By default how timing analysis will happen ? should we take any extra care for this phasehist clock for the timing analysis purpose ? NOTE: We are using MMCM *v files which are generated from the Vivado for synth and PNR. Any help or suggestions are highly appreciated. -Sampath & Krishna
-Sampath
0 Kudos
Highlighted
Moderator
Moderator
408 Views
Registered: ‎11-04-2010

Re: Timing Constraint for phase shifted mmcm output

Jump to solution

Hi, @ssampath ,

With the input clock of the MMCM, the tool will generate the output clock of the MMCM, and all the phase shift of the clock will be considered automatically.

The naming of the outout clock will not include the phase shift information automatically, you have to rename the output clock manually as you need. (Search rename in UG903).

You don't need to take any extra care for this phaseshift clock if all the analyzed paths are in the fabric of FPGA.

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

0 Kudos
Highlighted
392 Views
Registered: ‎01-17-2018

Re: Timing Constraint for phase shifted mmcm output

Jump to solution

Hi, @hongh 

 

As you mentioned, the tool will generate the output clock of the MMCM, and all the phase shift of the clock will be considered automatically

Is the above line applicable only when we are using .XCI file?    or also applicable for RTL files of generated MMCM ?

 

Thank you

0 Kudos
Highlighted
Moderator
Moderator
371 Views
Registered: ‎11-04-2010

Re: Timing Constraint for phase shifted mmcm output

Jump to solution

Hi, c.gannamani@gmail.com ,

The constraint handling is same for "XCI file" and "RTL files of generated MMCM".

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
337 Views
Registered: ‎01-17-2018

Re: Timing Constraint for phase shifted mmcm output

Jump to solution
Hi, @ ALL

Thank you for your valuable replies.
0 Kudos
Guide
Guide
304 Views
Registered: ‎01-23-2009

Re: Timing Constraint for phase shifted mmcm output

Jump to solution

You don't say what FPGA you are using...

When you are using an MMCM with phase shifted outputs, the tools can treat the phase shift in one of two ways based on the PHASESHIFT_MODE property of the MMCM.

With PHASESHIFT_MODE=WAVEFORM, the two clocks (the shifted and unshifted) are treated as two separate clocks. So taking an example of a 100MHz, clock with CLKA at 0 degress and CLKB at 90 degrees, you would have the following edges

  1. CLKA rise: 0ns
  2. CLKB rise: 2.5ns
  3. CLKA fall: 5ns
  4. CLKB fall: 7.5ns

With PHASESHIFT_MODE=LATENCY, you end up with the same timing, but there is a subtle difference - the shifted clocks are not separate clocks, but are the same clock with a latency delay, so they basically end up looking lie

  1. CLKA rise: 0ns
  2. CLKB rise: 0ns with 2.5ns latency
  3. CLKA fall: 5ns
  4. CLKB fall: 5ns with 2.5ns latency

While these look the same, they are very different. Take the example of a path that starts at the rising edge of CLKA and ends at the rising edge of CLKB. According to the rules of Vivado, the capture edge of a path is the first ideal (unpropagated) edge of the capture clock that is strictly later than the launch edge.

So in PHASESHIFT_MODE=WAVEFORM, a path launched at the rising edge of CLKA at 0ns will be captured at the rising edge of CLKB that immediately follows it, which is at 2.5ns resulting in a 2.5ns requirement for that path (which is what you would expect).

However, in PHASESHIFT_MODE=LATENCY, the same rule results in very different results. The rising edge of CLKA is at 0ns. The ideal rising edge of the unpropagated CLKB is also at 0ns, therefore it is not the one that would be the capture edge - the capture edge must be strictly after the launch edge. The next launch edge of CLKB is at time 10ns. So the path would actually end up being timed with a requrement of 10ns, and would have an additional 2.5ns delay on the destination clock path, which would effectively time this path at 12.5ns. This is incorrect.

So if you are planning to use clocks like this, you need to use PHASESHIFT_MODE=WAVEFORM. This is the default for 7 series and UltraScale devices, but for UltraScale+ (and presumably Versal), the default is LATENCY. So in UltraScale+ you would have to override it, which can be done in the XDC file, or (I believe) as an attribute of the MMCM when it is created (including through the clocking wizard).

Now, in case you are wondering why this was done, lets look at when you would want to use PHASESHIFT_MODE=LATENCY.

Take the example of a clock forwarded interface, where you need some delay of the forwarded data with respect to the forwarded clock. Lets say you use CLKC as the clock of the ODDR that forwards the clock, and CLKD as the clock of the IOB flip-flop that clocks the data (I will assume SDR data). As for the actual phaseshift between CLKC and CLKD, you need to determine that by doing some static timing analysis, and then adjusing the phaseshift to the right value for your interface.

Lets say that you (initially) try 0 as the correct value. Looking at the path from rising edge CLKC to rising edge CLKD, the path would be timed as a 10ns path - CLKC rises at 0ns and the next edge of CLKD is at 10ns.

Now, lets say, that you decide that you need to add 0.5ns of delay to CLKD to make the timing of the interface what you want. If the MMCM is in PHASESHIFT_MODE=WAVEFORM. then now this path, which still has a launch edge at 0ns, now has a capture edge at the next rising edge of CLKD, which is at 0.5ns! This is radically different than the previous result - in fact you have effectively removed 9.5ns from the path instead of adding 0.5.

However in this case, if PHASESHIFT_MODE=LATENCY, then the addition of the 0.5ns delay does not change the unpropagated clock, it is still at 0ns with a propagation latency of 0ns. So your path is still from CLKC at 0ns to CLKD at 10ns, but CLKD has an additional propagation delay of 0.5ns. This is what you want! So if you wanted this, this would be the default in UltraScale+, but you would have to override the default in 7 series and UltraScale.

So, one of the two modes is valid and correct based on what you plan to do - I have shown two cases, where, in one, the "intended" behavior is obtained by WAVEFORM mode and in the other it is LATENCY. So you need to take this into account when you design clocking structures and set the property the way you intend for paths to be timed.

Avrum