Genlock

I am looking to fix a problem while implementing Genlock inside the FPGA. It is for Video applications. The black burst generated locks to the external reference but has some jitter. Please reply if u can think of a solution.

Reply to
fpgavhdl
Loading thread data ...

We need a bit more information. Are you locking H to H? Are you generating the s/c from H with a ratio counter. Are you then pulling the s/c according tothe burst?

Give us a few lines of detailed description, and we might be able to help.

Reply to
Pete Fraser

Thanx...

The video module design is a black burst generator...which has two modes of operation.....When no external input is connected it has to run as a master free running black burst generator....whereas when an extrenal input is conected the black burst generated has to lock to the incoming video signal I am using an sync stripper and an external PLL which is locking the hsync generated from the sync stripper....ouput clk from the PLL along wth the Hsync is given to the FPGA....where I wanna lock the subcarrier.....which works fine....I mean it locks but with some jitter...which I guess is not acceptable...

Hope the details are fine...if u need more....let me know

Reply to
fpgavhdl

Is this NTSC? Are you locking at 858 x fh, 4 x fsc, or something else? Is your H jitter OK when free running and locked?

Are you synthesizing the sc from H with a ratio counter? Is the sc OK when free running?

What is your source? If you're using a ratio counter how big is it? Are you using integral plus proportional feedback from the demodulated burst to the accumulator seed? If so, how did you choose these values?

You might want to check out this paper:

formatting link

It's stuff I did over 25 years ago, but most if it is still valid. FPGAs are a lot faster than 74S283s and 74S374s, so you won't need to do things like factor the sc accumulator.

Reply to
Pete Fraser

Thanx Again

The black burst generator is both NTSC and PAL compliant...

I am locking the Hsync using a PLL (external to the fpga) using a 1715 x fh = twice 858 x fh ...which u were talking abt..

I cant get the Hsnyn without jitter. What do u mean by source?

The output from the PLL (which is clock of frequency 1715 x fh = 27 MHz) is then given to the FPGA. The FPGA does the Black burst generation...also does the subcarrier locking..where it has two modes of operation. One when the extrenal is given...where the Black burst generated locks to the external reference and the second when no external is given...in this case....it acts as a free running black burst generator. The PDF document looks really good and will be of great help.

Let me know if u need any more details...

Reply to
fpgavhdl

All PLLs will have some jitter - do you have some numbers on how much jitter you are seeing ?

If this is an external Analog PLL, it probably has a loop filter, so you can scope that to check it is actually in stable lock.

PLLs like this are also a trade off of lock-range vs stability. eg Colour burst PLLs use XTALS, very high stability, but quite narrow lock ranges. Horiz PLLs can use RC or LC circuits, RC are cheaper, but have higher jitter values.

-jg

Reply to
Jim Granville

So we have a problem right from the start. I didn't know if your jitter was in h or in sc.

Is it a test generator, a DVD player etc. If it's a non-tbc'd vtr that can cause interesting problems.

How much is the jitter? Presumably you have video coming into an LM1881 or such like. The output of your sync stripper will go to one input of the phase comp, and the divided VCO (from the FPGA) will go to the other. Stick a scope on these and measure the jitter.

What PLL chip are you using, or did you make it yourself?

The PLL should have a memory style phicomp; not xor.

How well filtered is the VCO supply?

How clean is the loop filter ground (FPGA noise)?

Is the VCO LC, XTAL or relaxation (bad)?

What is the resonant frequency and damping factor of the loop?

Are you getting pure H out of your sync stripper (i.e., check that there is no weird stuff going on in vertical)?

Reply to
Pete Fraser

By scoping the sync stripper (EL 4511) H sync seems to be jitter free. This Hysnc is given to the PLL which generates a 27 Mhz clock that is locked to the Hsync. This clock is fed into the FPGA which does the Subcarrier locking. The 27 MHz coming into the FPGA is upscaled to 54 MHz..during the rising edge of this 54 MHz clock the subarrier is locked to the reference input signal (composite video). Do u think this helps the subcarrier lock to the 54Mhz clock? The PLL chip I am using is a MK2069. BTW whats the technique to measure the jitter. Also the 27 MHz clock input to the FPGA is not a proper square wave...and as far i know this could be reason for jitter aswell. What do u have to say on this? The input analog video composite signal is converted into a 12-bit digital before giving to the FPGA (for locking the subcarrier). The output from the FPGA is given to the DAC which gives the analog black burst. Do u think since both these DAC and ADCs,which are operated with clock (not exactly square waves) will have anything to do with the jitter?

Thanx again...Really appreciate ur help

Reply to
fpgavhdl

I have not had time to read the MK2069 datasheet in detail but it seems a strange one for locking to H. The block diagram seems to show that you MUST divide horizontal by two before you get to the first phase comp. Genarally speaking, you want to have the highest possible comparison frequency. Assuming you have the PV dividers set to "2", then you should be able to lock your scope to RCLK (fh/2) and observe the relative jitter on ICLK (fh). The jitter is actually on RCLK, but it's easier to measure if you sync to the lower frequency input.

It might be better to allow the 2069 to do the frequency multiplication in its second PLL. The 2069 is designed to deal with any jitter on the primary VCO, but FPGA clcok multiplers tend to not tolerate input jitter well.

I'm not sure what you're saying here. Does your A/D run at 27 MHz or

54 MHz? I assume 54 MHz. Are you then half-band filtering? You should be using all the samples from the central 50% of the burst width. However, there's no need to be extremely super-Nyquist, so doing the demodulation at 27 MHz, or even 13.5 MHz should give you a decent burst lock (as long as you have a reasonable pre-decimation filter).

That could be a problem. Check the clock against the FPGA vendor's specs.

Unless they're so badly miss-clocked that they're munging samples It shouldn't be a problem.

You're welcome. What's the background to this design? What's it going to do when it's finished? Is it a commercial device or a hobby project?

Reply to
Pete Fraser

Sorry for not being prompt in replying to your mail. I was out for town for a week. The MK 2069 generates a 27 MHz clock. The 27 MHz clock generated by 2069 is locked to the Hsync, but when no Hsync it still generates a 27 Mhz clock..which is a little wierd.

Well I the clock generated by the PLL (after it is locked to the Hsync) is not exactly a 50 % duty cycle square wave. Can I use a square wave shaper? Will I lose the locked information if I do that.

BTW its my hobby to design projects for Televison Broadcasting applications....well if it works it might go commercial

Really appreciate ur help

Reply to
fpgavhdl

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.