cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
javitxu
Visitor
Visitor
463 Views
Registered: ‎09-17-2018

Source synchronous interface static phase alignment with MMCM

Jump to solution

Hi,

I have a source synchronous interface between an ADC (AD9249, https://www.analog.com/media/en/technical-documentation/data-sheets/AD9249.pdf) and a series 7 Zynq. Thanks to the advice I was given by @avrumw here https://forums.xilinx.com/t5/Timing-Analysis/Vivado-timing-analysis-for-a-source-synchronous-interface/m-p/1197739#M20579, I decided to restrict the sample rate to 20 MHz (so I have a 140 MHz clock for the interface). I want to use the phase offset utility of a MMCM to adjust the clock phase for the interface, but I am not sure of how to do so.

First of all, I am using the second clocking structure described here https://forums.xilinx.com/t5/Other-FPGA-Architecture/LVDS-DDR-input-constrains/m-p/694350/highlight/true#M16385. The relevant timing values for the FPGA I'm using are TPSMMCMCC/ TPHMMCMCC: 2.95/–0.23. Therefore, if I understand that correctly, I must have at the input pins a data window which at least covers the range from 2.95 to 0.23 ns before the capture clock edge. As my bit period is 3.57 ns (140 MHz at double data rate) and I lose 600 ps more due to uncertainties, I still have "enough window" to capture data. However, the ADC outputs data and clock with a 90 degree phase relationship, that is, it outputs a center-aligned clock. Thus the input capture window does not match the required interval and some alignment is required. 

I want to use the MMCM that is already present to align the data. If a rising edge of the ADC output clock happens at 0 ns, my (next) valid data would appear at 2.086 ns (half a bit period plus 300 ps uncertainty), and it would last until 5.057 ns. However, the required setup/hold interval at the input goes from 621 ps (falling edge @ 3.57 ns - 2.95 ns setup) to 3.34 ns (falling edge @ 3.57 ns + (-0.23 ns) hold). My idea then is to delay the clock by 1.58 ns (or about 80 degrees), but while using IDELAYS would make this easy to do, I am not sure that a 80 degrees shift in the MMCM achieves the same result. In fact, once I set that phase in the MMCM and I analyze the timing, the report shows that I still fail (see image attached).

I get that they are not the same clock, and that the input clock is the one that should be delayed. But if the MMCM is supposed to align its output to the clk at the input pin of the Zynq, don't the TPSMMCMCC and TPHMMCMCC values given by Xilinx take this into account?. And if they do not, how are you supposed to adjust the timing if not by trial and error, by analyzing the timing report and then adjusting the phase offset in the MMCM?. 

Thanks for any advice!

Timing.JPG
0 Kudos
1 Solution

Accepted Solutions
avrumw
Expert
Expert
430 Views
Registered: ‎01-23-2009

This is a common confusion with MMCMs.

First lets look at how the tools determine launch and capture edges. The capture edge of a setup path is the clock edge on the destination clock that is strictly after the launch edge of the source clock. This is done on the clock itself, before any propagation delays. So if you have a path where the source and destination are both on the same 100MHz clock (SDR), if the launch edge is at 0ns, the capture edge is the destination clock edge that is strictly after it, which is the edge at 10ns.

Now consider the same situation but the MMCM shifts the destination clock forward by 90 degrees. This results in the destination clock having edges at 2.5ns and 7.5ns.

Now look at the same rule. If the setup launch edge is at time 0, the destination clock edge that is strictly after it is the one at 2.5ns. While you intended to shift the clock forward by 2.5ns, the net effect is that the requirement on the clock comes down from 10ns to 2.5ns.

There are two ways to fix this. One is with a set_multicycle_path command. I am pretty sure the way to do this (I need to reverify it each time I use it) would be a "set_multicycle_path 2" on the path without a "set_multicycle_path -hold 1".

This is confusing and hard to manage. 

So, Xilinx added a way of controlling how the tools treat the MMCM delay - they added a property to the MMCM called PHASE_SHIFT_MODE. The default of PHASE_SHIFT_MODE is WAVEFORM for 7 series and UltraScale devices, but LATENCY for UltraScale+ devices. But, in either case, you can always override it in the MMCM instantiation or in the XDC file.

Take a look at this post on PHASE_SHIFT_MODE. In your case, what you want is the LATENCY behavior.

In your case, changing PHASE_SHIFT_MODE to LATENCY should fix this problem.

Avrum

View solution in original post

2 Replies
avrumw
Expert
Expert
431 Views
Registered: ‎01-23-2009

This is a common confusion with MMCMs.

First lets look at how the tools determine launch and capture edges. The capture edge of a setup path is the clock edge on the destination clock that is strictly after the launch edge of the source clock. This is done on the clock itself, before any propagation delays. So if you have a path where the source and destination are both on the same 100MHz clock (SDR), if the launch edge is at 0ns, the capture edge is the destination clock edge that is strictly after it, which is the edge at 10ns.

Now consider the same situation but the MMCM shifts the destination clock forward by 90 degrees. This results in the destination clock having edges at 2.5ns and 7.5ns.

Now look at the same rule. If the setup launch edge is at time 0, the destination clock edge that is strictly after it is the one at 2.5ns. While you intended to shift the clock forward by 2.5ns, the net effect is that the requirement on the clock comes down from 10ns to 2.5ns.

There are two ways to fix this. One is with a set_multicycle_path command. I am pretty sure the way to do this (I need to reverify it each time I use it) would be a "set_multicycle_path 2" on the path without a "set_multicycle_path -hold 1".

This is confusing and hard to manage. 

So, Xilinx added a way of controlling how the tools treat the MMCM delay - they added a property to the MMCM called PHASE_SHIFT_MODE. The default of PHASE_SHIFT_MODE is WAVEFORM for 7 series and UltraScale devices, but LATENCY for UltraScale+ devices. But, in either case, you can always override it in the MMCM instantiation or in the XDC file.

Take a look at this post on PHASE_SHIFT_MODE. In your case, what you want is the LATENCY behavior.

In your case, changing PHASE_SHIFT_MODE to LATENCY should fix this problem.

Avrum

View solution in original post

javitxu
Visitor
Visitor
411 Views
Registered: ‎09-17-2018

That was exactly the problem. Many thanks Avrum!

0 Kudos