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: 
Highlighted
Adventurer
Adventurer
248 Views
Registered: ‎07-24-2016

General Clocking Architecture Question

Jump to solution

Hi forum,

Suppose that an FPGA gets a reference clock from an on-board oscillator into one of its clock-dedicated pins. It then routes it out to an external device (jitter cleaner) on the same board. The jitter cleaner outputs a clock back into a transceiver-clock-dedicated pin of the same FPGA - to use as a reference clock for the transceiver.

If one wants to add the minimum amount of jitter to the clock, what is the best way to do this? Does it even matter, and does the jitter of the original oscillator play a role here?

1) clk_pin -> IBUFGDS -> BUFG -> ODDR
2) clk_pin -> MMCM -> BUFG -> ODDR
(MMCM in 'minimize output jitter' mode)

Thanks in advance!

0 Kudos
1 Solution

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

Re: General Clocking Architecture Question

Jump to solution

@cbakal 

I agree with Avrum that your questions don’t have definitive answers. You just gotta go through the analysis and see what jitter you end up with.

We can use Vivado to analyze how the FPGA affects jitter. For this I created a little project for a Kintex-7 that has the following circuits.
jitter_proj.jpg

CLK_IN0 and CLK_IN1 are both 100MHz clocks for which I can specify the jitter.   CLK_IN0 is sent through MMCM1 (set to minimize output jitter) and then forwarded out of the FPGA as CLK_OUT0.  CLK_IN1 is sent through a BUFG and then forwarded out of the FPGA as CLK_OUT1. The schematic also shows two registers that forward data out of the FPGA as DAT_OUT0 and DAT_OUT1. Adding some constraints (create_generated_clock on the forwarded clocks and set_output_delay on the forwarded data) gives two source-synchronous-output interfaces: (CLK_OUT0, DAT_OUT0) and (CLK_OUT1, DAT_OUT1).

After implementation of the project, you can generate a timing report using:

report_timing -to [get_ports DAT_OUT0] -setup

In generated report you will find the clock uncertainty section which is described on about page 98 of UG903. This section gives uncertainty on CLK_OUT0 and looks something like the following.

Clock Uncertainty:      0.058ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
     Total System Jitter     (TSJ):    0.071ns
     Discrete Jitter          (DJ):    0.091ns
     Phase Error              (PE):    0.000ns

Note that DJ is jitter on the clock-output of MMCM1 and TSJ is jitter added by other FPGA components. I found that changing jitter on CLK_IN0 had a fairly small effect on DJ. For example, I saw the following (input-jitter, DJ) combinations: (0.010, 0.090), (0.100, 0.091), (0.300, 0.104) – and no change in TSJ. That is, the MMCM is acting as a pretty good jitter-cleaner.

Similarly, you can study how jitter on CLK_IN1 affects jitter on CLK_OUT1 by looking at timing reports generated with:

report_timing -to [get_ports DAT_OUT1] -setup

From these reports you will find that TSJ=0.071ns (as before) and that jitter on CLK_OUT1 is simply the sum (in sum of squares sense) of TSJ and the jitter on CLK_IN1.

One can consider the MMCM and BUFG methods of passing a clock through the FPGA to be low-bandwidth and high-bandwidth approaches. The low-bandwidth (MMCM) approach will filter off much of the jitter on the clock-input to the FPGA and you end up with MMCM-produced-jitter on the clock-output of the FPGA. The high-bandwidth (BUFG) approach filters off none of the jitter on the clock-input. Thus, much of the jitter on the input-clock will appear on the output-clock.

Your second question about jitter-cleaners has an answer similar to what we found for the FPGA. That is, jitter-cleaners often use a phase-locked loop that can have a low-bandwidth or high-bandwidth setting (ref AN513).  With the low-bandwidth setting for the jitter-cleaner, the input-clock jitter has little effect on the output-clock jitter – and you end up with mostly cleaner-produced-jitter. However, with the high-bandwidth setting for the jitter-cleaner, much of the input-clock-jitter will appear on the output-clock.

-enjoy the journey,
Mark

2 Replies
Historian
Historian
186 Views
Registered: ‎01-23-2009

Re: General Clocking Architecture Question

Jump to solution

I don't have a definitive answer for  you, but...

If the oscillator is of good quality, then you probably don't want to go through the MMCM. The MMCM does a good job at removing jitter, but it also adds some fixed amount. So if your input clock has lots of jitter, the MMCM will reduce it significantly. However, if your input clock has very little jitter, the result after the MMCM may have more...

Also, using the BUFG is not the best idea. The global routing of the BUFG (particularly the clock spines) run straight through the center of the FPGA where they can pick up all kinds of induced noise.

The best way to do this is probably go from the clock capable pin to a BUFIO and from there directly to the ODDR and output pad for mirroring the clock. However, this only works if the clock capable input and the output are in the same I/O bank.

All this being said, if you are using a good external jitter cleaner, the difference in jitter between these different solutions is not likely to be terribly significant on the final clock after the jitter cleaner.

(But, again, I just want to warn you that all of the above is based on inference and guesswork - I don't think there is a definitive answer to this question).

Avrum

172 Views
Registered: ‎01-22-2015

Re: General Clocking Architecture Question

Jump to solution

@cbakal 

I agree with Avrum that your questions don’t have definitive answers. You just gotta go through the analysis and see what jitter you end up with.

We can use Vivado to analyze how the FPGA affects jitter. For this I created a little project for a Kintex-7 that has the following circuits.
jitter_proj.jpg

CLK_IN0 and CLK_IN1 are both 100MHz clocks for which I can specify the jitter.   CLK_IN0 is sent through MMCM1 (set to minimize output jitter) and then forwarded out of the FPGA as CLK_OUT0.  CLK_IN1 is sent through a BUFG and then forwarded out of the FPGA as CLK_OUT1. The schematic also shows two registers that forward data out of the FPGA as DAT_OUT0 and DAT_OUT1. Adding some constraints (create_generated_clock on the forwarded clocks and set_output_delay on the forwarded data) gives two source-synchronous-output interfaces: (CLK_OUT0, DAT_OUT0) and (CLK_OUT1, DAT_OUT1).

After implementation of the project, you can generate a timing report using:

report_timing -to [get_ports DAT_OUT0] -setup

In generated report you will find the clock uncertainty section which is described on about page 98 of UG903. This section gives uncertainty on CLK_OUT0 and looks something like the following.

Clock Uncertainty:      0.058ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
     Total System Jitter     (TSJ):    0.071ns
     Discrete Jitter          (DJ):    0.091ns
     Phase Error              (PE):    0.000ns

Note that DJ is jitter on the clock-output of MMCM1 and TSJ is jitter added by other FPGA components. I found that changing jitter on CLK_IN0 had a fairly small effect on DJ. For example, I saw the following (input-jitter, DJ) combinations: (0.010, 0.090), (0.100, 0.091), (0.300, 0.104) – and no change in TSJ. That is, the MMCM is acting as a pretty good jitter-cleaner.

Similarly, you can study how jitter on CLK_IN1 affects jitter on CLK_OUT1 by looking at timing reports generated with:

report_timing -to [get_ports DAT_OUT1] -setup

From these reports you will find that TSJ=0.071ns (as before) and that jitter on CLK_OUT1 is simply the sum (in sum of squares sense) of TSJ and the jitter on CLK_IN1.

One can consider the MMCM and BUFG methods of passing a clock through the FPGA to be low-bandwidth and high-bandwidth approaches. The low-bandwidth (MMCM) approach will filter off much of the jitter on the clock-input to the FPGA and you end up with MMCM-produced-jitter on the clock-output of the FPGA. The high-bandwidth (BUFG) approach filters off none of the jitter on the clock-input. Thus, much of the jitter on the input-clock will appear on the output-clock.

Your second question about jitter-cleaners has an answer similar to what we found for the FPGA. That is, jitter-cleaners often use a phase-locked loop that can have a low-bandwidth or high-bandwidth setting (ref AN513).  With the low-bandwidth setting for the jitter-cleaner, the input-clock jitter has little effect on the output-clock jitter – and you end up with mostly cleaner-produced-jitter. However, with the high-bandwidth setting for the jitter-cleaner, much of the input-clock-jitter will appear on the output-clock.

-enjoy the journey,
Mark