LMH1983 Video CLock Generator

James,  measuring sub ps jitter is very tricky - any small impedance discontinuity could account for the fs difference that you are seeing on the DJ, but 203ps of random jitter indicates that something is very wrong.   Your post refers to images, but the images did not seem to come through so I am not sure what they are referring to.   If NO_LOCK is asserted, then the part is not locking to your reference - can you give me details as to the reference that you are supplying to the part - what format is it, and where is it coming from?

Another thing that I would do is to look at the noise spectrum on a spectrum analyzer.  Often the frequency of the jitter gives you a good clue as to where it is coming from.

Mark

Mark,

The Hsync and Vsync signals are sourced from an HD Digital Image sensor from Aptina Imaging.  The Hsync (or Line Valid) and Hsync (Frame Valid) are generated and embedded into the Sensor's High Speed Serial Pixel (HiSPI) output Interface using sync codes.  A Lattice FPGA uses a HiSPI Receiver module (Verilog) to recover the pixel clock and Line/Frame Valid signals.  The sensor is configured for 1080P60 (2200 horizontal pixels by 1125 Lines).    At 60 Hz Frame rate using 1125 lines the line rate is (1/60) / 1125 lines = 14.8148 usec.  Now since the horizontal line is blanked for 220 out of the 2200 horizontal pixels, using the pixel rate (tpixel = 6.734ns) the horizontal blank period is 220 * 6.734ns = 1.48148 usec.  The vertical blanking period is 45 lines out of 1125 or 14.8148usec * 45 = 666.66 usec.  Since we're using progressive here the field is zero.  This format code would be #12 on page 10 in the data sheet.  We're not using CLock 2-4 output only clock 1 (27MHz) as the external reference applied to the Aptina Sensor.  The Sensor then creates the pixel clock and line/frame valid signals.

James

My understanding is that you are using the 27 MHz output clock from the LMH1983 and using that to drive the Aptina sensor - the Aptina sensor will multiply this up to the 148.5MHz pixel clock rate internally, and then divide the pixel clock rate down to get the H and V outputs - you shouldn't need (or indeed want) to then use these as a reference for the 1983, since they will already be locked to the 27MHz output.   I don't think that you would want to have the LMH1983 in locked mode - but rather allow it to free run.  You can fine tune the frequency by writing to the 0x19 and 0x18 registers.   Regardless, NO_LOCK will be asserted since the LMH1983 is going to be free-running.   If you want the sensor output to be synchronized to a second reference signal, then you can provide the H, V, F signals from the reference signal to the LMH1983, and the sensor output will then be locked to the reference.

If you want to get a SMPTE 424  signal out, you can use the 148.5MHz clock output from the LMH1983, and it will already be synchronized to your sensor output.

In looking at the scope shots that you sent to John, I am concerned about the 'hitch' that is on the edges of your clock - this looks like some sort of a reflection, and might indicate that there is an impedance mismatch on the trace  connecting the 27MHz output to the sensor.   That is almost certainly the cause of the unusually high jitter measurements that you are seeing.  It looks like the CLK1 output goes directly to the FPGA - does the FPGA have the 100 Ohm termination resistor internal and enabled?

Mark

Mark,

No the internal FPGA 100 ohm differential termination is not enabled.  I'm using LVCMOSD33 IO_TYPE and the FPGA software tools won't let me set any differential resistor value?  However on the HiSPI interface (DDR 297MHz) which uses IO_TYPE LVDS25 I can select either 80, 100 or 120 OHMS.  I sent an email to the Lattice FAE to ask how one uses 100 Ohm Differential resistor value when using IO_TYPE = LVCMOSD33.  Maybe I should use the LVDS25 IO_TYPE? We'll see!

Thanks

jimj 

Mark,

Enabled the LVDS IO type for the differential clock input and then selected 100 Ohm internal input termination.  No change still seeing the jitter on clock.  We still have the LMH1983 in GEN_LOCK mode.  Tommorrow will place in Free run and set the control voltage.

jimj

JimJ

Did you notice any difference to the shape of the rising edge on your clock signal after you enabled the 100Ohm termination - there was a little shelf at about the midpoint of the transition.

Mark

Mark,

I don't see the little shelf at about the midpoint of the transition but the amplitude is cut in half from 2.1V to 920mv (measured differential.  ALso the jitter is significantly reduced.

With termination;

Total JItter = 67.2ps; Random jitter 2.8ps(spec 2.7ps); Deterministic JItter = 27.2ps(spec 250fs)

Without Termination:

Total JItter = 1641ps; Random jitter 65.7ps(spec 2.7ps); Deterministic JItter = 721ps(spec 250fs)

 IF I run the PLL1 in the free run mode versus Genlock won't I have a significant increase in phase noise leading to more jitter?

jimj

It looks like properly terminating your clock line has helped quite a bit with your jitter.

Free run should not increase jitter at all, if the PLL is locked, you can expect noise at a frequency which is below the loop bandwidth of the PLL to track through the part (the loop bandwidth should be set to a frequency below the lowest frequency that you need to worry about), but in free run, the control voltage to the VCXO will be a DC voltage, eliminating that as a noise path to the output.

Mark,

I really think this problem has to do with the fact that the LMH1983 PLL1 is on the GENLOCK mode and since it isn't locking it goes into HOLDOVER by default.  Even after I enabled the 100 ohm termination and saw a significant reduction in the CLKOUT1 jitter, the 3G SDI outputs changed very little.  I can trace the poor jitter performance all the way back to the input differential serial clock (297MHZ) to the Lattice FPGA from sensor.  See the image (screenshot) thats inserted.  It looks like the frequency is wandering back and forth around 400ps.  Could this be from the PLL1 in free run mode and the holdover value changing ever so slightly back and forth?

jimj

JimJ

As I understand your system, you CANNOT operate in Genlock mode - Genlock synchronizes PLL1 to an external reference.  In your system, the reference is the H.V.F from your sensor, but the sensor is referenced to the PLL1 output - so the LMH1983 is chasing it's own tail, trying to lock itself to itself, which is only generating jitter and instability.   In your application, I believe that you should run the LMH1983 in free-run or holdover mode, and it will then generate a stable 27MHz clock that you can provide to your sensor, and it will also generate a 148.5 MHz clock which will be locked to the 27MHz clock.   Since the sensor is being clocked synchronously, the data will be aligned with the 148.5 MHz clock.

Mark

Mark,

We complete our I2C C function for the LMH1983, added it to our main app running on the embedded processor within the Lattice FPGA.  Now we have PLL1 configured for Free run mode and all the clocks except CLKOUT1 in HiZ mode since we're only using the 27MHz.  The 27MHz reference clock goes through the FPGA to the sensor connector.  I had a sysCLOCK PLL inbetween the input and output ports (to connector).  I removed the PLL because I thought it might be producing the time shifting in the output sensor HiSPI interface serial clock(297MHz) since its not an analog but digital synthesized PLL.  Take a look at the inserted image still getting the clock shifting in time coming out of the aptina .

You see the sensor has a PLL, Multiplier and Dividers in the clock path between the 27MHz input and the HiSPI serial output(297MHz).

Jim

I am not familiar enough with the Aptina sensor but one thought would be rather than using the jittery 297MHz output, use the 148.5MHz output from the LMH1983 coming from the CLK2 output - this clock should be phase locked (you can verify by looking at the 297MHz output and the 148.5 MHz outputs on the scope at the same time.)

Mark

Mark,

Since I've run out of ideas using the external LMH1983 148.5MHz for the pixel clock is a graet one to try.  The HiSPI interface within the Lattice FPGA does have a Dual Port RAM that I can use the external 148.5MHz as the read clock instead of the 297MHz/2.  Great suggestion hope it removes the excessive jitter on the input sclk (297MHz).

jimj

Let me know how it turns out.

Thank you

Mark