LMK03328: Jitter Performance of LMK03328 as REFCLK for Artix-7 GTP Transmitter

Conor,

I have a few questions here:

1. Are you saying that the LMK03328 would need to be able to accept an input of either 148.5MHz or 74.25MHz dynamically? Or would they only need one of these two frequencies (and the F/1.001) in the system?
2. Must the 12.288MHz clock be generated by the LMK03328? Or can this be generated by another device, such as CDC6C?
3. Do you have the phase noise requirements available that you can share?

Thanks,

Kadeem

Hi Kadeem,

Thank you for your follow-up. Please see below the our responses to your questions:

1. Input Clock Switching Behavior
The recovered clock frequency is selected dynamically according to the SDI video input format, as shown below:

1080i59.94, 1080p29.97 → 74.25 / 1.001 MHz

1080p59.94 → 148.5 / 1.001 MHz

1080i50, 1080p25, 1080i60, 1080p30 → 74.25 MHz

1080p50, 1080p60 → 148.5 MHz

The LMK03328 will need to accept one of these input clock frequencies depending on the input format.
Dynamic switching occurs only when the SDI video format changes. During normal operation, the system is locked to a single input bit rate, so the input clock remains fixed unless the video format is changed.

The 148.5 MHz or 148.5 / 1.001 MHz clock generated from the recovered clock will be used as the REFCLK for the GTP transmitter in the Artix-7 FPGA.

2. 12.288 MHz Audio Clock Generation
The 12.288 MHz audio clock must be generated by the LMK03328.
Due to input clock frequency and internal VCO operating constraints, the actual output frequency will be 12.287999 MHz.

3. Artix-7 GTP REFCLK Jitter Requirement
We are referring to Xilinx Answer Record AR#44549 – "7 Series FPGA GTX_GTH_GTP Transceivers - Reference Clock Phase Noise Masks" as the reference for the GTP transceiver’s REFCLK jitter and phase noise requirements.

Please let us know if you need any additional technical details or diagrams. We appreciate your support.

Best regards,

Conor

Connor,

1. If only one of these frequencies needs to be accepted based on the input format, and the input format is known in advance, then this may not be an issue. GPIO2 and GPIO3 can be configured to select different EEPROM pages. One page can support the 74.25MHz clock, and another can support the 148.5MHz clock. Based on your diagram, the only clock output is 148.5MHz, NOT 74.25MHz, correct?
2. This will require using both PLLs, one for the 148.5MHz and another for the 12.288MHz. My concern here is that we may not achieve optimal jitter cleaning, but we can take data for this and have an idea by Monday.

Thanks,
Kadeem

Hi Kadeem,

Kadeem Samuel said:

If only one of these frequencies needs to be accepted based on the input format, and the input format is known in advance, then this may not be an issue. GPIO2 and GPIO3 can be configured to select different EEPROM pages. One page can support the 74.25MHz clock, and another can support the 148.5MHz clock. Based on your diagram, the only clock output is 148.5MHz, NOT 74.25MHz, correct?

We are considering using the LMK03328 to support four different input clocks: 74.25 MHz, 74.25/1.001 MHz, 148.5 MHz, and 148.5/1.001 MHz.
Would it be possible to use only GPIO2 and GPIO3 to switch between all four configurations by selecting different EEPROM pages? Also, 74.25MHz is not used for output.

Kadeem Samuel said:

My concern here is that we may not achieve optimal jitter cleaning, but we can take data for this and have an idea by Monday.

We look forward to your feedback.

Thanks,

Conor

Conor,

We are working on the data collection.

GPIO2 and GPIO3 can be used to select the EEPROM page, just note that this cannot be done dynamically. The page needs to be selected at startup. Toggling the PDN pin as well can be done to change the page, per the below diagram:

Thanks,
Kadeem

Conor,

Apologies for the delay. I'll be able to have the jitter measurements tomorrow.

Best,

Cris

Hi Cris,

We are waiting for the results of the jitter characteristic evaluation measurement.

The following is a supplementary explanation of the configuration using two PLLs simultaneously.

◎To create a video output clock of 148.5 MHz and 148.351648351648 MHz, the PLL Loop BW setting must operate in Narrow band Mode. For input clocks of 74.25 MHz and 74.175824175824 MHz, the Doubler at the LMK03328 input must be set to ×2. The effect on the output clock is an increase in spurious signals.

◎To create an audio output clock of 12.288 MHz, the PLL Loop BW setting must operate in Fractional-N Mode.

Thanks,

Conor

Hi Cris,

We have reviewed the jitter measurement results you kindly provided and would like to confirm the following understanding:

Even when using both PLLs on the LMK03328 simultaneously (PLL1 for 148.5 MHz and PLL2 for 12.288 MHz), the output jitter performance appears to be sufficiently good. Based on your measurements, we believe it meets the jitter requirements for the Artix-7 GTP transceiver (<1 ps).
Furthermore, regardless of whether the input clock is 74.25 MHz or 148.5 MHz, the output jitter remains stable and no significant degradation is observed.

Could you kindly confirm if this understanding is correct?

Conor

Hi Cris,

We have reviewed the data and would like to ask a few questions regarding the output jitter performance.

According to the results shown in the slide, a low-jitter input clock (e.g., 148.5 MHz with approximately 144 fs RMS jitter integrated over 12 kHz to 20 MHz) is being provided. However, the measured output jitter of the 148.5 MHz LVPECL output is approximately 462 fs RMS.

Since the output jitter is more than three times higher than the input, we would like to confirm the following:

1. Is this level of jitter increase expected due to the LMK03328’s PLL architecture and LVPECL output buffer characteristics?

2. Could this level of output jitter cause any issues when used as the reference clock (REFCLK) for the GTP transceiver in Xilinx Artix-7 devices?
   (Reference: Xilinx Answer Record #44549)

We would appreciate your insights on whether this behavior is within expectations, and whether any optimization or configuration adjustments might be necessary.

Thanks,
Conor

Conor,

1. Yes this is expected due to crosstalk between the two PLLs and the output drivers.

2.

Conor said:

we believe it meets the jitter requirements for the Artix-7 GTP transceiver (<1 ps)

Based on the <1ps spec, I am not concerned about the output jitter causing issues. However in the phase noise spec, the LMK03328 is violating the 10kHz spec by ~8dB. I will work on the bench to see if I can meet this spec. Expect an update on Monday.

Best,

Cris

Hi Cris,

Thanks for your comment. I look forward to your feedback on your bench testing.

Thanks,

Conor

Hi Cris,

Thank you for sharing the test data.

We shared the updated jitter results with our customer, and while they understand that the results meet the AR#44549 requirements, they have a few concerns:

• They noticed several spur noises between 10kHz–100kHz and 100kHz–1MHz in the phase noise plot.

• Their application involves HD/3G-SDI over long coaxial cables, which can increase random jitter and degrade the recovered clock at the FPGA receiver.

• Given the limited margin near 10kHz (as you mentioned), they are slightly concerned about stability in their actual system.

Could you please let us know if there are known use cases or customer examples where LMK03328 has been used with Artix-7 GTP without jitter-related issues? That information would help build confidence in proceeding with this configuration.

Thanks,

Conor

Conor,

Previous designs that leverage the LMK03328 with the Artix-7 for SDI also use the LMH1983 (https://www.ti.com/lit/ds/symlink/lmh1983.pdf). What I am seeing is that the LMH1983 accepts a 27MHz local clock and outputs 148.5 or 74.25 MHz, 148.5/1.001 or 74.25/1.001 MHz, and 98.304 MHz / 2^X (X = 0 to 15) - the last clock being X=4 for a 12.288MHz output. I expect that this use case was that the LMK03328 takes in the 148.5 or 74.25 MHz or 148.5/1.001 or 74.25/1.001 MHz and generates the jitter-cleaned version of the clock, with the 12.288 coming from the LMH1983 instead. This solution is from five years ago, I have not heard of any issues with jitter or stability during this time.

This leads me to ask - what is different in this project where the 148.5/74.25MHz clocks now come from the Artix-7 directly? Needing to make the 12.288MHz from the LMK03328 as well is what leads to almost all of these spurs on the phase noise plot, as there is PLL-PLL crosstalk with both PLLs active. This is especially true when one operates in fractional mode (required for making 12.288MHz from 27MHz).

Thanks,
Kadeem

Hi Cris,

While reviewing the file named “LMK03328-148p5Input-Updated.tcs”, we noticed a possible discrepancy in the configuration.

According to the file name and context, we expected the configuration to use a 148.5 MHz input clock. However, when opening the file in TICSPRO1, the PRIREF input is actually set to 27 MHz, with a doubler enabled to generate 54 MHz before reaching PLL1 and PLL2.

Since the performance evaluation and phase noise behavior can vary significantly depending on the input clock source and frequency, we would like to confirm:

Was the intention behind this .tcs file to represent a 148.5 MHz input use case? If so, would it be possible to obtain a corrected version of the .tcs file that reflects direct 148.5 MHz input to LMK03328, in line with the test case？

Also, can you provide the configuration parameter information for the evaluation?
- LMK03328-148p5Input-Updated.tcs
- LMK03328-74p25Input-Updated.tcs

Thanks,

Conor