Modern equivalent of 74HC4046 PLL?

[Miti]

I hope you're all doing well,

I'm looking for a PLL/VCO chip that can extract the pixel clock from the horizontal sync pulses. The pixel clock is 21MHz, the horizontal sync is around 15KHz.
I tried HC4046 and used this calculator for the passives:

https://www.changpuak.ch/electronics/calc_03.php

It is very jittery and it only reaches 21MHz with C1 out of specs, <40pF when it needs to be >40pF. I suspect 15KHz is a bit low and the VCO is pushed to the limits.
The divider is in an FPGA and that part works well.

Do you know any simple chip that can do that?

Thanks!

[Karel]

Never use that chip, use the Nexperia 74HCT9046 instead. It's much more stable.

https://assets.nexperia.com/documents/data-sheet/74HCT9046A.pdf

[jpb]

This application note might be relevant:
https://www.ti.com/lit/an/scaa088/scaa088.pdf
It is audio but at similar frequencies going from a few 10s of KHz to 10s of MHz.
The 4046 is only used for its phase detector while another chip is used for the PLL.

[Kleinstein]

For slightly higher speed there is a 74LV4046.

[Miti]

Thanks for your replies and I apologise for my slow response. I was busy with... life.

@ Karel
Yes, I read somewhere that 4046 is crap. I used TI HC404AM because it is specified at 3.3V but I guess I need 5V to make it work at 21MHz. Or at least get the least crappiness out of it.

@jpb
Nice and clean solution but it is quite expensive and it needs I2C and a pullable 21MHz crystal. Unfortunately Digikey doesn't carry any 21MHz crystal.

@Kleinstein
I'm trying to find a 3.3V device first.

Technically I only need a VCO that can do 21MHz, I can implement the phase and frequency comparator inside the FPGA.

[NiHaoMike]

What are the capabilities of the PLLs built into the FPGA?

[SiliconWizard]

What are the capabilities of the PLLs built into the FPGA?

Yes, I had focused on the 4046 in my thoughts and just noticed that the OP was actually using an FPGA. Could be worth seeing if the embedded PLL(s) could do the job indeed. Thing is, with such a low input frequency, I highly doubt it would fit the specs of any FPGA's PLL... From what I remember, the min input frequencies are usually in the order of a few MHz?

I haven't taken a deep look, but the OP could take a look at Silab's offering: https://www.silabs.com/timing/clock-generators
maybe something appropriate there.

Edit: something still available and that looks like a possible fit: https://www.idt.com/document/dst/9173b-datasheet
typical "Genlock" PLL.

[jpb]

Thanks for your replies and I apologise for my slow response. I was busy with... life.

@jpb
Nice and clean solution but it is quite expensive and it needs I2C and a pullable 21MHz crystal. Unfortunately Digikey doesn't carry any 21MHz crystal.

Technically I only need a VCO that can do 21MHz, I can implement the phase and frequency comparator inside the FPGA.

I see your point about 21MHz - it seems a rather awkward frequency. There are some stand alone oscillators.

Even going up to 42MHz (which could be followed by a divide by 2) it falls at the edge of two - both of which are quite expensive :
38MHz - 42MHz
https://www.digikey.co.uk/product-detail/en/crystek-corporation/CVCO55CL-0038-0042/CVCO55CL-0038-0042-ND/4356641
or
42MHz - 46MHz
https://www.digikey.co.uk/product-detail/en/crystek-corporation/CVCO55CL-0042-0046/744-1164-ND/1644079
going up to 84MHz with a divide by 4 and there is one centred on 85MHz but that is getting a bit silly:
https://www.digikey.co.uk/products/en/crystals-oscillators-resonators/vcos-voltage-controlled-oscillators/173?k=&pkeyword=&sv=0&pv640=291304&sf=0&FV=-8%7C173&quantity=&ColumnSort=0&page=1&pageSize=25

[Miti]

What are the capabilities of the PLLs built into the FPGA?

15KHz is too low for the FPGA PLL. Cyclone 2 minimum PLL clock frequency is 10MHz, Cyclone 4 is 5MHz.

[Miti]

Edit: something still available and that looks like a possible fit: https://www.idt.com/document/dst/9173b-datasheet
typical "Genlock" PLL.

SiliconWizard you are a ...wizard 
That IC is exactly what I was looking for. Actually after a google search for "Video Genlock", I found that ICS9173B (01, 15) is identical to MK9173-01, MK9173-15.
This answers my question in another post, this one https://www.eevblog.com/forum/projects/part-identification-236714/ , where I'm trying to identify a part marked HX73-15 or so I thought. In fact it is MK73-15 (which translates into MK9173-15) but the low resolution picture made it look like HX or HK.

Thank you sir!
Cheers!

[Miti]

Ok, so I bought this chip MK9173-15 from Ebay, US seller, good communication, all seems legit  . It kind of works. I input ~15KHz and it outputs 21MHz. The jitter however is horrible but the LCD module doesn't seem to care.
Is this expected from a genlock chip like this or is it because I bought from Ebay?

[Zoli]

...
The jitter however is horrible but the LCD module doesn't seem to care.
...

Because you have a good "eye pattern"?
/ducks
I mean, the HF(21MHz) signal statistically is "cleanly" centered over the referece(15kHz) falling edge.
Of course, it would be nice to have a clean, jitterfree 21 MHZ, but I think, as long as the display doesn't care, why should you?
/hides

[Miti]

Of course, it would be nice to have a clean, jitterfree 21 MHZ, but I think, as long as the display doesn't care, why should you?

Well, the input to this circuit is the video output of an HP8591E spectrum analyzer that I want to up-convert to 1024x768 VGA. I wonder how sampling would be affected by the jitter. I have 95ns to sample the pixel so if I don't have a clock right in the middle, with the added jitter, my sample may be garbage.

[SiliconWizard]

You don't need an edge "right in the middle". You just need to have some reasonable leeway.

[BrianHG]

Ok, so I bought this chip MK9173-15 from Ebay, US seller, good communication, all seems legit  . It kind of works. I input ~15KHz and it outputs 21MHz. The jitter however is horrible but the LCD module doesn't seem to care.
Is this expected from a genlock chip like this or is it because I bought from Ebay?

For that degree of jitter, I would just use the 74HC4046 tuned to 10.5MHz.  Then in your FPGA, 2x that to the required 21MHz.  The clock would be much cleaner as you can tune your loop filter with the 74HC4046.  There are other modern PLL IC from TI which require a crystal/resonator which have a analog input tuning pin.  I made a video genlock using this chip where 100% inside the FPGA, I do the phase comparison and feed 2 outputs to charge and discharge that PLL analog vcxo input.  The resulting clock had no measurable jitter on my 5gsps 500Mhz Tektronix scope while a fixed 5v crystal oscillator had clearly visible jitter after 1/15000 of a second from trigger. (TI's CDCE913 1pll /CDCE925 2pll vcxo.  Tuning range is narrow for crystal at +/-150ppm, much more leeway for resonator, but the clock 60ps jitter performance is great and you have the option of 2 plls for other needs and a 160MHz range.)

Also for generating a clock from a 15Khz signal being a sync from a video source, divide that sync by 2 in the FPGA, giving you a 50/50 7.5KHz signal out to feed your 74HC4046 phase comparator.  It's phase locked loop lock capabilities are far superior when fed 50/50 duty cycles reference sources.  Also, in the FPGA, make sure you specify Fast input and Fast output registers in the assignments for the associated IOs when generating these phase reference timing outputs so that build-2-build, you will always get the same phase offset response down to an exact picosecond unless you alter the structure of the code involved with generating those signals.

[dmendesf]

Seems you got spread spectrum for free...

[Miti]

Seems you got spread spectrum for free...

  Yes...

[BrianHG]

Ok, so I bought this chip MK9173-15 from Ebay, US seller, good communication, all seems legit  . It kind of works. I input ~15KHz and it outputs 21MHz. The jitter however is horrible but the LCD module doesn't seem to care.
Is this expected from a genlock chip like this or is it because I bought from Ebay?

Have you considered that the PLL has generated a clean clock and the H-Sync coming from your source has jitter in it?
You might be able to check this by locking onto 2 H-syncs and zooming into the second one on the right to the current timebase to see if there is any built up jitter.
You can also do this with the PLL chip.

Also, have you analog isolated the PLL chip from your digital side.  This includes using series resistors to feed the phase comparator inputs and clk output to decouple any high frequency leakage working it's way back into the PLL vco.

[Miti]

Have you considered that the PLL has generated a clean clock and the H-Sync coming from your source has jitter in it?
You might be able to check this by locking onto 2 H-syncs and zooming into the second one on the right to the current timebase to see if there is any built up jitter.
You can also do this with the PLL chip.

I did my first tests with the FY6600 signal generator and I think that contributed to the terrible jitter. I remembered then that the generator may be jittery on square wave and, sure enough, it was. Then I moved to the HP SA itself, no jitter there and the clock has improved a bit but it is still jittery. I don't have a screen shot of that.

Also, have you analog isolated the PLL chip from your digital side.  This includes using series resistors to feed the phase comparator inputs and clk output to decouple any high frequency leakage working it's way back into the PLL vco.

You mean adding some series resistors to the IN, FBIN and Clock outputs? What values?

[BrianHG]

Have you considered that the PLL has generated a clean clock and the H-Sync coming from your source has jitter in it?
You might be able to check this by locking onto 2 H-syncs and zooming into the second one on the right to the current timebase to see if there is any built up jitter.
You can also do this with the PLL chip.

I did my first tests with the FY6600 signal generator and I think that contributed to the terrible jitter. I remembered then that the generator may be jittery on square wave and, sure enough, it was. Then I moved to the HP SA itself, no jitter there and the clock has improved a bit but it is still jittery. I don't have a screen shot of that.

Also, have you analog isolated the PLL chip from your digital side.  This includes using series resistors to feed the phase comparator inputs and clk output to decouple any high frequency leakage working it's way back into the PLL vco.

You mean adding some series resistors to the IN, FBIN and Clock outputs? What values?

100 ohm should do.
As for the supply, I would use a ferrite bead, of if the PLL is really low power, 10 to 100 ohm series with a 100nf and 10uf to GND.
Make sure you probe after the 100 ohm, not on the IC pin so that potential emi doesn't make it back into the pll.

[BrianHG]

I am curious.  If you are using an FPGA and you only need to sample pixels at 21MHz, or 10.5MHz, why bother with an external PLL?  In the FPGA, why not just operate the core, or video input at 210MHz, and software PLL select the appropriate 1 in approximate every 10 samples.  No funny low frequency sync clock regeneration.  Your end results will be finer than the jitter noise you are currently getting with external clock generation.

In fact, you can use 2 PLLs in the Cyclone, 1 from a reference crystal to generate an approximate 420 MHz (A clean chosen multiple of the H-Sync frequency + 1 clock cycle would work best), software synth a reference between 5 MHz to 10 MHz to feed a second PLL input, then use that one to generate a clean 21Mhz clock using the low-bandwidth mode to drive your LCD module.  Your overall jitter should be below 2ns.  Expect below 4ns jitter if you run the sync sampler at a more modest 210 MHz.

[Zero999]

Why use an RC oscillator for 21MHz?

Use an LC oscillator instead. A VCO can be made by using a varactor diode for the capacitance, or part of it.

[BrianHG]

Yes, the old Amiga genlocks which generated the reference 28.63636MHz used an LC oscillator which was 1 transistor, 1 tuning diode, tuneable inductor & usually a 74HC04 to buffer the clock plus a bit of logic to drive the tuning voltage from the incoming Hsync and Amiga's Hsync output.  Vsync was driven back into the Amiga video port where the computer internally moved it's Vsync position.

No oscillator needed for his design since he is using it to capture so low resolution 2 bit color B&W image while having an FPGA with 4 plls in it which can run circles around a single pixel width with something like 10x oversampling.

[Miti]

I am curious.  If you are using an FPGA and you only need to sample pixels at 21MHz, or 10.5MHz, why bother with an external PLL?  In the FPGA, why not just operate the core, or video input at 210MHz, and software PLL select the appropriate 1 in approximate every 10 samples.  No funny low frequency sync clock regeneration.  Your end results will be finer than the jitter noise you are currently getting with external clock generation.

In fact, you can use 2 PLLs in the Cyclone, 1 from a reference crystal to generate an approximate 420 MHz (A clean chosen multiple of the H-Sync frequency + 1 clock cycle would work best), software synth a reference between 5 MHz to 10 MHz to feed a second PLL input, then use that one to generate a clean 21Mhz clock using the low-bandwidth mode to drive your LCD module.  Your overall jitter should be below 2ns.  Expect below 4ns jitter if you run the sync sampler at a more modest 210 MHz.

Very interesting idea! The video clock is 10.5MHz divided from a 21MHz oscillator. The VGA clock is 55.125MHz. So I’ll have to generate something around 420MHz from a 25 or 50 MHz oscillator, then divide it down to about 10MHz while resetting the divider at the end of every line on the rising edge of the HSync, then feed this clock to another 2 PLLs to make 21MHz and 55.125MHz.
Did I get this right?

[BrianHG]

Yes, really close, except 420MHz is overkill while 210MHz will do and since it is a short input counter section, you will not have any trouble with the FMAX on the slowest cyclone.  Even 420 might work, but this is not how you do this if you want an easy sample pixel clock source.  There are a few minor tricks to get a few controls and optional second PLL to get this to work the way you want.

Item #1, is the pixel sample clock actually 10.5MHz on the dot, or 21MHz on the dot?
Item #2, you need to know how many clock 10.5/21MHz cycles it is from H-Sync to H-Sync, not how many pixels are on the screen.  It is also important to know if this is an odd number.  I've writen the rest assuming it is an even number.

Next, if 21MHz is the right figure, choose a core clock frequency 16x this figure:
This means make 1 PLL in the cyclone 336MHz from your 25/50MHz source.

Make a sync UP counter with sync reset (not async) with 6 bits.

Next for the sync input.
First make that registered.
Then with a second clk delay register, make a falling edge transition detector which will be the reset for your counter.

Note that at stage 2 in developement, you will want to make this reset a selectable/programmable pipe delay of 1 to 32 clock cycles as this will adjust the sample phase of you pixel sampling period so you may grab pixels on the center sweet spot.

Next, make a registered output tied to bit 4 (starting at bit 0) of this counter.
This output will contain your new 10.5MHz clock.

If Your H-Sync pixel clock divides into 4, use bit 5 for a reference 5.25 MHz clock, otherwise you may need to switch to 10.5MHz on bit 4.

In Quartus, just tie bit 5, 5.25MHz into a second 1:4 PLL to generate a new system 21MHz with a 'low bandwidth' setting.
That 'low bandwidth' setting slows down the Cyclone's PLL phase alignment to below 1 MHz smoothing out that potential +/- 2ns glitch once every few H-Syncs.  That's your new pixel sampling clock.  (Make it a 1:2 if the true pixel sampling is only 10.5MHz)

If you have any HDL troubles, or some added features to remove H-Sync noise, or transfer sampled data between clock domains, make a new thread in the 'FPGA' section of this forum.  Note I can only really help with Verilog or System Verilog or Quartus block diagram entry.

Looking at you current scope PLL jitter snapshot, this solution directly outputting bit 3 or 4 of you counter should reveal a 10.5/21MHz clock with +/-1.5ns jitter around the H-sync if any at all.  Unless your scope crystal clock is junk, this should roast your current PLL scope shots.

Outputting the second PLL from the cyclone with the low bandwidth setting generated from that clock would have a smoothed out effect.

As for the screen you are driving.  There usually is enough play to operate it from a fairly clean multiple of the 10.5MHz clock, but, the cyclone's pll is quite capable of doing simultaneous fractional outputs from 1 PLL, so it can easily make the 55.125 along the filtered 10.5MHz or 21MHz clock, or even all 3 clocks.

[BrianHG]

You have got to be kidding me....
Ok, you will need to use 2 PLLs to get the 336MHz.
PLL #1 to switch from 25/50MHz to 21MHz.
PLL #2 to go from 21MHz to 336MHz.
Otherwise, you will end up with an odd clock frequency value of 336.11111MHz if you use 1 PLL.
Or, if you have a different reference oscillator which can divide cleanly into 336MHz like 27MHz, or 8MHz/16/24/32MHz, 54MHz, 13.5MHz ect...

If you have 3 PLLs in your Cyclone, this project will work fine with any oscillator you already have.
This changes is the sample clock is actually something slightly different like 10.4MHz or 10.6MHz.

[Miti]

No oscillator needed for his design since he is using it to capture so low resolution 2 bit color B&W image while having an FPGA with 4 plls in it which can run circles around a single pixel width with something like 10x oversampling.

I’ll be using a Cyclone 4 in TQFP 144 package. It has two PLLs only.

[Miti]

You have got to be kidding me....
Ok, you will need to use 2 PLLs to get the 336MHz.
PLL #1 to switch from 25/50MHz to 21MHz.
PLL #2 to go from 21MHz to 336MHz.
Otherwise, you will end up with an odd clock frequency value of 336.11111MHz if you use 1 PLL.
Or, if you have a different reference oscillator which can divide cleanly into 336MHz like 27MHz, or 8MHz/16/24/32MHz, 54MHz, 13.5MHz ect...

If you have 3 PLLs in your Cyclone, this project will work fine with any oscillator you already have.
This changes is the sample clock is actually something slightly different like 10.4MHz or 10.6MHz.

Don’t worry, I’ve checked, 24MHz would do it.

[BrianHG]

You have got to be kidding me....
Ok, you will need to use 2 PLLs to get the 336MHz.
PLL #1 to switch from 25/50MHz to 21MHz.
PLL #2 to go from 21MHz to 336MHz.
Otherwise, you will end up with an odd clock frequency value of 336.11111MHz if you use 1 PLL.
Or, if you have a different reference oscillator which can divide cleanly into 336MHz like 27MHz, or 8MHz/16/24/32MHz, 54MHz, 13.5MHz ect...

If you have 3 PLLs in your Cyclone, this project will work fine with any oscillator you already have.
This changes is the sample clock is actually something slightly different like 10.4MHz or 10.6MHz.

Don’t worry, I’ve checked, 24MHz would do it.

Yup, 24 MHz multiplies x 14 to perfectly make 336MHz.
2 PLLs will work fine.
Making a 6 bit counter run at 336MHz will also be not problem.
Since your 336MHz clock will either be ever so slightly slower or faster than the scope's H-sync generated from the 10.5MHz, your final total correction jitter will be an occasional 2.976ns skip in 1 direction.

     I haven't a clue, but if you can get a 6 bit counter running at 672MHz, this occasional corrective skip will be down at 1.488ns at a time.  Having a code configured fixed phase alignment setting wouldn't be a problem, but you most likely could not get a software controlled one operating at 672MHz unless it's a -6 Cyclone, or just something ingeniously designed.

     Clocking a second PLL from the top bit of the 6 bit counter with the low bandwidth loop filter will make that PLL slowly adjust it's rate to align to these skips filtering out any abrupt transition step.  That second PLL can simultaneously make you sample clock and video output clock.

     Though, if you have a little flexibility on that VGA clock, like running it at 52.5MHz and using a different horizontal sync, front, and back porch values, this figure squarely divides into selecting a single core clock of 105MHz.  Where you output the VGA every second clock and sample video every 5th or 10th clock.

[BrianHG]

Oh, 1 thing... You will need to drive an output pin with the counter bit[5], then tie that pin to an input to drive the second PLL.  Quartus doesn't like an internal logic cell driving the clk input of a PLL.

Make sure you make assignments:
fast output register for the counter bit[5]
and
fast input register for the sync inputs and video data inputs.

This way, as long as you register the inputs to a PLL clock as well as registered output, each compile build you make will have identical phase timing.  Otherwise, after each build, depending where the fitter places the logic, your phase delay will drift due to internal routing of the FPGA fabric.

In my designs, I usually fast input & fast output register all IOs in my designs at the minor possible cost of reaching an FMAX.  The usual fix is just an additional pipe-lined clocked register.

[BrianHG]

Also, when testing, lock your scope onto the Hsync input and place a second probe on the counter[5] output.  Make sure you get a 50/50 duty cycle on that clock output through and just after the sync pulse.  If it appears deformed in any way other than the potential +/-1.5ns jitter, you have done something wrong or have the wrong values from the scope's video output.

Extending the view across the picture should reveal a clock relatively locked to the pixels.

[Miti]

How do you assign fast registers? When I do that in assignment editor, the PIN number disappears from the pin planner.

[BrianHG]

Here is how you do it.
Enter the Assignment Editor.

Go to the bottom of the list and click on <<new>> like in my illustration #1.
Enter the NET pin name like in my illustration #2.
Select the assignment feature like in my illustration #3.
Select 'ON' like in my illustration #4.  (Read added note...)

Click anywhere else, as if it is accepted, the new assignment line text will turn black.
Next, 'Save' in the file menu to save the addition to your assignments.

My guess is you might have entered a pin number instead of the net name assigned to the pin.

[Miti]

Got it, thank you!
Actually what I did was to change the existing pin from location to fast register. Now I understand that both must be there.

[BrianHG]

This way, you can change you pin out, but wherever you place the pin, Quartus knows that the 'net' name's associated logic needs to have it's logic cell located to the one right at the chosen IO pin creating as close to no delay as possible.
 

[Miti]

If I set input frequency to 5.25MHz, I get a bandwidth error. I will make the up counter 5 bits and feed the second PLL from cnt[4], 10.5MHz.

[BrianHG]

No problem.

Key 1 is when you scope the sync (ie trigger on sync in) into the FPGA and the counter's 5th bit out [bit 4 if you start at bit 0], you see a 50/50 duty cycle 10.5MHz square wave through the sync alignment time with only a +/- 1.5ns of jitter.  It shouldn't get any fatter of thinner on a high or low.  (Accounting for that total possible 3ns correction phase.  Remember, PLL#1 at 336 MHz isn't really locked to anything.)

Key 2, when scoping the output of the second PLL locked onto that 10.5MHz reference, it's slight jitter isn't really any worse.  The rest of your video design may now be run off of that PLLs outputs.  This output should not have that 3ns correction, but it will still have slight phase jitter noise as it slowly catches up with the introduced 3ns correction around 20 to 50 clock cycles later.  In any case, it should roast what you have shown so far with the dedicated external PLLs.

[Miti]

I think I've got it. In "Without HSync", HSync is connected only to the scope, not to the FPGA.
I used my FY6600 and I know it is jittery on square by design.
Tomorrow I will try with the spectrum analyzer but I have to level shift from 5V to 3.3V.
I've also attached the raw code, please criticize mercilessly... 

Edit: I added 21MHz and 55.125MHz screen shots with frequency counter.

Code: [Select]

module Default
(
//////////////////// Clock Input ////////////////////
CLOCK_24, // 24 MHz
EXT_CLOCK, // External Clock
RESET,
DRAM_CS_N, // SDRAM Chip Select
//////////////////// VIDEO IN ////////////////////////////
HSYNC_IN, // HSync in
OUT_10,
IN_10,
CLK_OUT_21,
CLK_OUT_55

);

//////////////////////// Clock Input ////////////////////////
input CLOCK_24; // 24 MHz
input EXT_CLOCK; // External Clock
input RESET;
//////////////////////// Push Button ////////////////////////

output DRAM_CS_N; // SDRAM Chip Select

////////////////////////////////////////////////////////////////////
input HSYNC_IN;
output OUT_10;
input IN_10;
output CLK_OUT_21;
output CLK_OUT_55;

wire CLK_336;

// All inout port turn to tri-state

assign DRAM_CS_N = 1'b1;

reg [4:0] CNT_PLL;

reg Pll_reg0;       
reg Pll_reg1;
 
wire Hsync_neg_pulse;

assign Hsync_neg_pulse = Pll_reg1 & (~Pll_reg0);
assign OUT_10 = CNT_PLL[4];

always@(posedge CLK_336)
begin
Pll_reg0 <= HSYNC_IN;
Pll_reg1 <= Pll_reg0;
end

always@(posedge CLK_336)
begin
if(Hsync_neg_pulse)
CNT_PLL <= 5'b00000;
else
CNT_PLL <= CNT_PLL + 1'b1;
end

Input_PLL u0 (
.inclk0(EXT_CLOCK),
//.inclk0(CLOCK_24),
.c0(CLK_336)
); // PLL module input clock

Output_PLL u1 (
.inclk0(IN_10),
.c0(CLK_OUT_21),
.c1(CLK_OUT_55)
); // PLL module output clock

endmodule


[BrianHG]

Raw code is fine, other than you do not need both 'always@(posedge CLK_336)', just 1 will do.

If it works fine on the scope, all you need to add is an adjustable 16 step shift on the reset (4 bits) and a 1 bit invert for the clock out (5th bit) which gives you a programmable 32 step/position phase offset for the 10.5Mhz clock so you may center you sample time on the center sweet-spot of the incoming video.

If you are sampling at 21MHz, then you only need the 4 bits for 16 positions.

Also, since you will probably be delaying the hsync input, pass an H-Sync out of your 336MHz after the programmable delay so that when you sample the hsync in the 21MHz section, you wont get horizontal sync jitter on a few lemon horizontal phase settings.

Tadaa, you now made the phase setting for the PLL in this IC:
https://www.ti.com/product/TVP7002

[BrianHG]

Question:
If your scope is locking on the falling edge of the 'Sync in' only (yellow channel), why do I see 2 drop points 3ns apart?

I know the clocks might look messier if you sample only the 'Sync in' without that glitch, but it will tell you the degree of horizontal jitter noise a sample be during the width of a pixel.  That is if you zoom out to capture 2 h-syncs, then magnify into a few pixels so long as you scope has enough memory to not drop the sample rate.

Other than that, yes what I see roasts your old external PLLs.

[Miti]

Question:
If your scope is locking on the falling edge of the 'Sync in' only (yellow channel), why do I see 2 drop points 3ns apart?

I know the clocks might look messier if you sample only the 'Sync in' without that glitch, but it will tell you the degree of horizontal jitter noise a sample be during the width of a pixel.  That is if you zoom out to capture 2 h-syncs, then magnify into a few pixels so long as you scope has enough memory to not drop the sample rate.

Other than that, yes what I see roasts your old external PLLs.

That's exactly what I did. The screen shots are zoomed-in on the falling edge of the next HSync after the trigger point, ~64us delay.
The double falling edge of the HSync is coming from the FY6600 signal generator which is jittery on square wave on frequencies other than those with a period that is multiple of 4ns.
https://www.eevblog.com/forum/testgear/feeltech-fy6600-60mhz-2-ch-vco-function-arbitrary-waveform-signal-generator/1875/

That's why I said that I will try later with the HSync from the SA which is jitter free.

[Miti]

Other than that, yes what I see roasts your old external PLLs.

I totally agree! And about the title of this topic, I don't think you can find any more modern equivalent of HC4046 than this...

[Miti]

Raw code is fine, other than you do not need both 'always@(posedge CLK_336)', just 1 will do.

Like this?

Code: [Select]

module Default
(
//////////////////// Clock Input ////////////////////
CLOCK_24, // 24 MHz
EXT_CLOCK, // External Clock
RESET,
DRAM_CS_N, // SDRAM Chip Select
//////////////////// VIDEO IN ////////////////////////////
HSYNC_IN, // HSync in
OUT_10,
IN_10,
CLK_OUT_21,
CLK_OUT_55

);

//////////////////////// Clock Input ////////////////////////
input CLOCK_24; // 24 MHz
input EXT_CLOCK; // External Clock
input RESET;
//////////////////////// Push Button ////////////////////////

output DRAM_CS_N; // SDRAM Chip Select

////////////////////////////////////////////////////////////////////
input HSYNC_IN;
output OUT_10;
input IN_10;
output CLK_OUT_21;
output CLK_OUT_55;

wire CLK_336;

// All inout port turn to tri-state

assign DRAM_CS_N = 1'b1;

reg [4:0] CNT_PLL;

reg Pll_reg0;       
reg Pll_reg1;
 
wire Hsync_neg_pulse;

assign Hsync_neg_pulse = Pll_reg1 & (~Pll_reg0);
assign OUT_10 = CNT_PLL[4];

always@(posedge CLK_336)
begin
Pll_reg0 <= HSYNC_IN;
Pll_reg1 <= Pll_reg0;

if(Hsync_neg_pulse)
CNT_PLL <= 5'b00000;
else
CNT_PLL <= CNT_PLL + 1'b1;
end

Input_PLL u0 (
.inclk0(EXT_CLOCK),
//.inclk0(CLOCK_24),
.c0(CLK_336)
); // PLL module input clock

Output_PLL u1 (
.inclk0(IN_10),
.c0(CLK_OUT_21),
.c1(CLK_OUT_55)
); // PLL module output clock

endmodule


[BrianHG]

Yes, that's perfectly fine.

[BrianHG]

Other than that, yes what I see roasts your old external PLLs.

I totally agree! And about the title of this topic, I don't think you can find any more modern equivalent of HC4046 than this...

Well, if you really wanted to ultimately get it as good as possible, with some much better clever coding, like running 2 long period counters at the top 500MHz, one on the positive clock and the other on the negative clock, with an emulation of the PC2 on the 4046 either letting the counters run free, subtract 1 or add 1 once in a huge period of the HS coming in, we can shrink that +/- 1.5ns jitter down to 0.5ns.  However, if the old external PLL worked with that +/-10ns jitter, +/- 1.5 should be fine.  Just adding a second neg_clk counter to your current logic with a little careful DDR output trick feeding the Cyclone's second PLL would cut your current theoretical +/-1.5ns jitter in half.

Basically we would be making your design appear to be operating at 672MHz and we would be using second's PLLs low bandwidth to average 2 of the reference counters driving the same current output pin in a swapping MUX configuration, basically using the output pin the same way a DDR output is driven, except the swap from n-counter bit 5 to the p-counter bit 5 would only be done once after every 2 or 4 10.5mhz cycles.  To verify this would be functioning properly, you would want a scope with at least 5 GSPS.  (IE: if your scope maxes out at 500MSPS, how do you expect to debug the fine transition timing of a 672MHz clocked source?)


Either that, or on the output 10.5MHz output pin, feed it in series through a 1pf cap or even a FM radio 10,5MHz ceramic IF filter to a tuneable inductor/transistor amp with a bandwidth below 7KHz and feed that transistor's output into the CLK input back into the Cyclone erasing all remaining jitter so long as the transistor amp and circuit board analog noise is well isolated from the circuit.

[Miti]

My DSO is Rigol DS1054Z, it is 1GS/s. Can’t I just observe the difference in jitter?

[BrianHG]

Yes, you may be able to just make out a difference.
Remember, if your scope has the input bandwidth, with a 672MHz clocked output, your scope will only acquire 1 sample before the transition and part of one after.  With a 5GSPS scope, you have 7 samples going through each clock output transition.  The trick I mentioned involves monitoring the cyclone PLL bandwidth speed in the 'Low bandwidth' setting meaning we will want to measure jitter noise in the 0.2-0.5ns range.  A perfect 1GSPS scope with 2 channels at 1GSPS (not an interleaved 500MSPS) could only measure 1ns of jitter per sweep.  You actually do get even a bit more measurement resolution due to input analog bandwidth limitation and the scope's sinX/X interpolation.

First get your clock locked to your scope.  If it's sync output is clean enough and your 24MHz feeding the Cyclone is clean enough, or the Cyclone PLLa power supply is free of noise, and you want to try the 672MHz PLL as an exercise to compare the jitter before and after, let's go right ahead.  When I say clean enough, I mean you can see the distinct 3ns hops before the H-Sync re-alignment takes place on the second PLL's 21/10.5MHz output with the current 336MHz version.

I think at that point, you could not do any better unless you go back to a high quality vcxo and prepare a precision analog section for your PCB layout to eliminate all external EMI.

[BrianHG]

Your 1054z is 500Msps with 2 channels on:


If you could still lock on sync in with channel #1, but turn channel 1 off and view the clock on channel #2 at 1GSa/s still locked to sync in on channel #1, then yes you can see much finer 2x detail.

This is one of those thing wheres when it comes to lower bandwidth/budget equipment, a 100Mhz analog scope might reveal more.

Remember your first single snapshot of the external PLLs, it looked clean until you locked onto the H-Sync and viewed the 2 signals at the synchronization point.  the kind of jitter you are looking for is a slow long term analysis of a clock & how it's phase deviates over that 15KHz period.  Not clock cycle to clock cycle which will look clean on any scope other than a spectrum analyzer with low frequency FM demodulated noise/purity measurement capabilities.

[BrianHG]

Other than that, yes what I see roasts your old external PLLs.

I totally agree! And about the title of this topic, I don't think you can find any more modern equivalent of HC4046 than this...

Your topic and location was in the wrong place.  I only found it by luck in with your other thread in the FPGA section.

If you made your topic in the FPGA section:
'Is it possible or Can you make a Cyclone PLL lock onto a 15KHz video source for a sampler clock?'
You would have never had to bother playing with any PLL ICs in the first place.

Though, you would never know how tricky it is to make those ICs operate in a clean behaved manner.

[Miti]

Your 1054z is 500Msps with 2 channels on:

Yes but I can still see the jitter if I trigger on the output of interest and then move the trigger point to the left. Using only one channel.

[Miti]

Other than that, yes what I see roasts your old external PLLs.

I totally agree! And about the title of this topic, I don't think you can find any more modern equivalent of HC4046 than this...

Your topic and location was in the wrong place.  I only found it by luck in with your other thread in the FPGA section.

If you made your topic in the FPGA section:
'Is it possible or Can you make a Cyclone PLL lock onto a 15KHz video source for a sampler clock?'
You would have never had to bother playing with any PLL ICs in the first place.

Though, you would never know how tricky it is to make those ICs operate in a clean behaved manner.

I didn’t plan for a digital PLL inside the FPGA.

[Miti]

Other than that, yes what I see roasts your old external PLLs.

I totally agree! And about the title of this topic, I don't think you can find any more modern equivalent of HC4046 than this...

Well, if you really wanted to ultimately get it as good as possible, with some much better clever coding, like running 2 long period counters at the top 500MHz, one on the positive clock and the other on the negative clock, with an emulation of the PC2 on the 4046 either letting the counters run free, subtract 1 or add 1 once in a huge period of the HS coming in, we can shrink that +/- 1.5ns jitter down to 0.5ns.  However, if the old external PLL worked with that +/-10ns jitter, +/- 1.5 should be fine.  Just adding a second neg_clk counter to your current logic with a little careful DDR output trick feeding the Cyclone's second PLL would cut your current theoretical +/-1.5ns jitter in half.

Basically we would be making your design appear to be operating at 672MHz and we would be using second's PLLs low bandwidth to average 2 of the reference counters driving the same current output pin in a swapping MUX configuration, basically using the output pin the same way a DDR output is driven, except the swap from n-counter bit 5 to the p-counter bit 5 would only be done once after every 2 or 4 10.5mhz cycles.  To verify this would be functioning properly, you would want a scope with at least 5 GSPS.  (IE: if your scope maxes out at 500MSPS, how do you expect to debug the fine transition timing of a 672MHz clocked source?)


Either that, or on the output 10.5MHz output pin, feed it in series through a 1pf cap or even a FM radio 10,5MHz ceramic IF filter to a tuneable inductor/transistor amp with a bandwidth below 7KHz and feed that transistor's output into the CLK input back into the Cyclone erasing all remaining jitter so long as the transistor amp and circuit board analog noise is well isolated from the circuit.

Looking at the jitter on the scope I don’t think it is necessary but it’s an interesting exercise, so let’s do it.
So two 5 bits counters, one always @(posedge) and the other always @(negedge).
Bit4 (counting from 0) of both counters connected to a MUX. The rest of the circuit doesn’t change.
The MUX is switched by another counter after every 2 - 4 cycles. Who clocks that counter?

[BrianHG]

Ok, I've done a few timing simulations.  After experimenting around, there was only 1 way to get consistent clean output results.  Negative edge clock was not used.  All that was needed was the 'ALTDDIO_IN' megafunction for the sync input.  This function automatically sets up a bunch of hidden timing corrections to some internal registers so the the sync in is captured on the rising and falling edge of the 336MHz clock, however, the results of the previous negative edge capture are delayed and are presented on the positive edge of the next clock.  Basically it has 1 input, 2 outputs, dataout_h, dataout_l.

Here is the simulation I came up with.
Note that 'clk_outa' is what feeds the input of the second PLL.
Output 'clk_fix' is a test output for visualization of the internal counter generating th 10.5MHz clock.
Notice what happens to 'clk_outa' when I shift the falling edge of 'SYNC_IN' by half a 336MHz clock at a time.



Now, because you are operating with a DDR input sampling at 672MHz when the theoretical limit is 500MHz, there were some things I had to set in Quartus to get reliable results.  It doesn't matter what your reported FMAX is, the outputs get skewed and the input sampling phase timing isn't as reliable without these changes.

In assignment settings, compiler settings:
1. Choose Speed or Performance, not Balanced or anything with 'Area' in the settings.
2. Do not prevent register retiming.  It is needed for the DDR input.
3. In advanced settings, make sure 'Power Optimization During Synthesis' is turned off.
4. In Fitter advanced settings, make sure 'Power Optimization During Fitting' is turned off.

In the project's pinout:
1. At minimum, your SYNC_IN should be on a DDR_DQ IO pin on a high speed IO bank.  (If I remember correctly, the top & bottom IO banks are high speed and left and right side ones are slower, however, this is on BGA I don't know about QFP)
2. It is preferable that your 10.5MHz clock output is in the same IO bank.

This will make your design run as fast as possible.  Not that it's going any faster than 336MHz, but the IO pin timing will be tight enough that you will capture that half-clock cycle SYNC_IN with high enough quality phase that it will inprove your PLLs overall jitter.

Here is the System verilog code I wrote to generate the output:

Code: [Select]


module MITI_PLL_Divider (
        input  logic clk,
        input  logic sync_inh,
        input  logic sync_inl,
        output logic clk_out,
        output logic clk_fix
        );

logic   [5:0]  counter, counter_dl;
logic   sync_inh_reg, sync_inl_reg;

always_ff @(posedge clk) begin

sync_inh_reg <= sync_inh;
counter_dl   <= counter;
clk_out      <= (counter_dl[5] && sync_inl_reg) ? counter_dl[4] : counter[4];

clk_fix      <= counter[4];

if (!sync_inh && sync_inh_reg) begin
                               counter      <= 0;
                               sync_inl_reg <= sync_inl;
                      end else counter      <= counter  +1;
end // @posedge clk

endmodule



[BrianHG]

Yes, it is possible to use a 'ALTDDRIO_OUT' and properly set it datain_h and datain_l so that you may generate a data_out with a half phase delay instead of my jump ahead and back every full clock cycle, however, you will need to simulate the results to guarantee you get the tricky part right during a change in alignment.  Again, there will be no negedge clock.  And this time around, the 10.5MHz clock output pin will require it be placed on a DDR IO output pin in the same high speed IO bank as the SYNC_IN DDR input.

[BrianHG]

Ok, ok, ok, twist my leg...
Here is the perfect solution using the DDR output which makes a near perfect 10.5MHz clock which will have a theoretical +/- 0.7ns jitter, so long as the Hsync coming in doesn't have any jitter of it's own.

Code: [Select]


module MITI_PLL_Divider (
        input  logic clk,
        input  logic sync_inh,
        input  logic sync_inl,
        output logic clk_out_h,
        output logic clk_out_l,
        output logic clk_fix
        );

logic   [5:0]  counter, counter_dl;
logic   sync_inh_reg, sync_inl_reg;

always_ff @(posedge clk) begin

sync_inh_reg <= sync_inh;
counter_dl   <= counter;
clk_out_h    <= sync_inl_reg ? counter_dl[4] : counter[4];
clk_out_l    <= counter[4];

clk_fix      <= counter[4];

if (!sync_inh && sync_inh_reg) begin
                               counter      <= 0;
                               sync_inl_reg <= sync_inl;
                      end else counter      <= counter  +1;
end // @posedge clk

endmodule



[BrianHG]

Judge the difference for yourself...

[BrianHG]

This should roast your reference function generator's 4ns jitter.

[Miti]

Judge the difference for yourself...
(Attachment Link)

So half a clock shift vs one clock shift. I don't speak system verilog but seems easy to translate to verilog.
By DDR_DQ IO pin, you mean one of those pins marked with Q in the pin planner, but use it as 3.3V TTL default, right?

[BrianHG]

To translate to verilog, except for the inputs, the 'logic' changes to 'reg'
input 'logic' changes to input wire.
'always_ff' changes to 'always'.

You can completely get rid of the 'clk_fix'.

Any IO voltage you use will work with 'ALT_DDIO_IN/OUT'.

As for the ALTDDIO_IN&OUT, they are in the mega IP store in the IO section.  Just set those up the same way you did your current PLLs in your existing code.  As long as you don't cross up the _h and _l, the code should make a clean clock.

Yes, on the top or bottom set of IOs for the FPGA, any IO pin would do.  Stick to 1 IO bank with a PLL in it for best results.  Just remember that in the future, you may want to reserve a dedicated PLL output pin if you will be clocking something like a ram chip.

Also, when feeding the 10.5MHz out back into the FPGA, the closest dedicated CLK input is usually the best choice.

The columns on the sides will also work, however, their response is a little slower.

I tried to simulate this design on Quartus Prime 18, LOL, it wouldn't even provide a clock output (it worked in functional mode, but not timing mode) and everything was dead due to Quartus believing that the PLL cant output a 336MHz clock though Quartus 9 seems to disagree.  An yet, your HDL was already clocking at 336MHz.

[BrianHG]

To compare the DDR to the SDR version, just change this line:

Code: [Select]

clk_out_h    <= sync_inl_reg ? counter_dl[4] : counter[4];
to:

Code: [Select]

clk_out_h    <=  counter[4];
Or, make an new input wire ' enable_ddr ' and do this:

Code: [Select]

clk_out_h    <= (sync_inl_reg && enable_ddr) ? counter_dl[4] : counter[4];
So you may switch the DDR on and off in real-time when testing.

[Miti]

Now, because you are operating with a DDR input sampling at 672MHz when the theoretical limit is 500MHz, there were some things I had to set in Quartus to get reliable results.

So we’re exceeding the maximum frequency of Cyclone 4? Is that a good idea and can I expect repeatable results between chips and between boards?

[BrianHG]

Well, we are keeping that 336MHz internal.  It's only driving 18 registers.  Quartus compile timing report says that the FMAX is well above the 400MHz space, but the 'Restricted FMAX' is 250MHz.  This restriction is in place because they do not want you to drive IO pins with a signal greater than 250MHz.  The problem here is if you try to output the 336MHz, even on a dedicated PLL output pin.  That pin will need to open and close an N-channel and P-channel mosfet 672 million times a second without overlap, otherwise, that small transition time when both mosfets draws more current than what that section of the IC may be designed to do, including trying to charge and discharge the capacitance on the IO pin itself, and this current can get huge especially if you have a BGA with 128 IOs doing all this switching at the same time at the same speed.  In fact, reading deep into the Intel Cyclone data sheets, there actually are total IO usage limits with particular current settings, or particular IO standard settings on the chip at top frequencies.

Tell me, does your current PLL design make the FPGA burn your finger?

For this PLL, we are getting away with it since our 1 output pin never exceeds switching at 10.5MHz and 1 input at 15KHz.  If you need to output a clock of the first 336MHz PLL, though the 336 might will make it through, I would recommend making the PLL have a second output at 1/2, 168MHz, and feed that to the PLL output pin.

Here, I strategically chosen the IOs on 1 bank where a PLL is located running the MITI_PLL for a Cyclone III 144pin QFP, 3.3v LV TTL mode.  (Basically equivalent to the Cyclone IV, but Quartus 9 only simulates Cyclone III and later versions of Quartus no longer simulate designs).


Now here is the new timing simulation with the strategic IO settings:



Notice how much better the DDR IO trick creates an in between clock cycle compared to my last simulation where the IO went anywhere on the FPGA.

When you make your design, I'm expecting you will not output a 336MHz clock.
If you are really afraid, you can always run the PLL at 168MHz instead and use the DDR trick to achieve an equivalent 336MHz function which you already have now without the DDR.

(I have a sneaky suspicion when you use the ALT_DDIO_xxx function, they are clocking the final pin IO register with either 2 phases from the PLL clock, or at 2X speed with a dedicated shift register to move that half phase data back onto your main CLK for your logic.  I cannot achieve such clean DDR timing by any other means other than using the ALT_DDIO megafunction other than overclocking the design to 2x speed.)

[BrianHG]

Intel/Altera may have just made it policy to kill the simulation results just at the clock reaches 250MHz since they figure no one would bother create such a simple 20 register design which can run above 250MHz , yet not do anything complicated.  I guess it's a lack of imagination.

[Miti]

Tell me, does your current PLL design make the FPGA burn your finger?

Far from that, the board only takes 80mA from 5V running only the PLL.

[BrianHG]

Ok, so I guess we are waiting for you to place a resistor divider terminator for the scope 5v sync output into the cyclone & scope the PLL out in both SDR336MHz and the new DDR336MHz mode.

[BrianHG]

The Quartus Prime simulation failure is clearly a bug.  Here it is, right from the Cyclone IV data book:



Do not worry, we are completely in the clear unless your CycloneIV is the slowest low power version -9L...
Also notice my previous post FMAX and the -8 PLL maximum clock frequency.
Including the Fout to the dedicated PLL output pin which has a 472.5MHz limit.
I guess you can output the 336MHz if you want.

[Miti]

Brian, something happened to the firsts attachment in #61, it is the same with the one in #65.

[BrianHG]

Brian, something happened to the firsts attachment in #61, it is the same with the one in #65.

I know EEVblog has recently been corrupting attachments along may different posts for different people for some reason.
Give me a sec, I kept the originals just in case.  I'll re-upload the attachments right now.

Done, I checked them, they are OK as of 5:27 est GMT -5:00.

[Miti]

And here it is. PLL1 is the one without DDIO, PLL2 is with DDIO. The screen shots are with HSync from the spectrum analyzer and 10 seconds persistence. They are captured at the trigger point and one line (next HSync pulse) after the trigger point. Apparently there is a bit of jitter in the SA clock as well but the results are much better. 5V supply current is 82mA.

Thanks Brian, this works great!!!

Edit: The forum does what it wants with the attachments. Arrgh!
Edit1: I added some pixel shots. There's always a 21MHz falling edge of the 21MHz clock right in the middle of the pixel. With a simple inverter I could make that the write clock for the dual port RAM. And that is an extra indication that the clock is locked on the pixel (well HSync) clock.

[BrianHG]

10 second persistence, I don't think you will have trouble either sampling the video from the scope with that clock as you were zoomed into 5ns per division & I think your pixel width was 100ns.  Using the PLL2, the jitter seemed to be under 1 division, 2.5ns, a little worse than my predicted 1.4ns.  Though, with all the accumulated noise around, quality of scope's internal clock & TTL driver sync output, & I don't know if your FPGA PCB has a dedicated supply layer for the analog PLL supply, you are doing an order of magnitude better than the dedicated PLL with it's 25ns jitter.

Should have done the measurements with only 2 channels active so you get 500MS/s instead of the 250MS/s.

Ok, you have 1 chore left, just add the ability to shift the 21MHz output phase with a 4 bit input to you verilog code giving you 16 select-able positions + a pass through of the H_Sync_in with that carried delay to prevent horizontal alignment capture jitter.

[BrianHG]

Also, you are zoomed in too close.  What I really want to see is the beginning of the sync trigger at the left of the scope, and 20ns/div, only viewing the sync in and the DDIO output pin, not PLL#2.  This will show us how the counter is behaving during hsync reset, like is it being squished or stretched.  remember, that output DDIO output 10.5mhz reset takes effect something like 10-15ns after the h-sync in and we want to see a full cycle.  You should be scoping only on every h-sync to view this one right.

This will prove that the clock of 21MHz divides into a perfect integer of the scopes H-sync.

Right now, you cannot see the reset trigger point as it takes place further to the right of you scope shot.

[BrianHG]

Edit1: I added some pixel shots. There's always a 21MHz falling edge of the 21MHz clock right in the middle of the pixel. With a simple inverter I could make that the write clock for the dual port RAM. And that is an extra indication that the clock is locked on the pixel (well HSync) clock.

Look carefully at your pixel clock scope shots.  It's the rising edge of the cyan colored clock which always grabs the middle sweet spot of a pixel where it's analog vertical height stabilizes.  I'm counting each video element on the screen being 2 pixels wide at 21MHz.  The falling edge of the cyan clock is on the edges of a pixel.  Yet, you wont find out much until you grad the data coming into the cyclone as the inputs have a delayed setup time.  At 15Khz, this means your video coming out has a vertical resolution of something like 1024 pixels, ie 1024x240.  A little odd.  I would have suspected that the true sampling clock was 10.5 MHz making a screen res of 512x240.

Just like TTL logic using a resistor divider to drive a pseudo analog dac, it also seems that the video out of you scope falls slightly faster than it rises.  Easy to see when you have a clean sampling clock overlayed on your oscilloscope image.

[Miti]

Also, you are zoomed in too close.  What I really want to see is the beginning of the sync trigger at the left of the scope, and 20ns/div, only viewing the sync in and the DDIO output pin, not PLL#2.  This will show us how the counter is behaving during hsync reset, like is it being squished or stretched.  remember, that output DDIO output 10.5mhz reset takes effect something like 10-15ns after the h-sync in and we want to see a full cycle.  You should be scoping only on every h-sync to view this one right.

This will prove that the clock of 21MHz divides into a perfect integer of the scopes H-sync.

Right now, you cannot see the reset trigger point as it takes place further to the right of you scope shot.

Like this? I can't see neither squish nor stretch.

[Miti]

Look carefully at your pixel clock scope shots.  It's the rising edge of the cyan colored clock which always grabs the middle sweet spot of a pixel where it's analog vertical height stabilizes.  I'm counting each video element on the screen being 2 pixels wide at 21MHz.  The falling edge of the cyan clock is on the edges of a pixel.  Yet, you wont find out much until you grad the data coming into the cyclone as the inputs have a delayed setup time.  At 15Khz, this means your video coming out has a vertical resolution of something like 1024 pixels, ie 1024x240.  A little odd.  I would have suspected that the true sampling clock was 10.5 MHz making a screen res of 512x240.

Nope, the pixel clock is 10.5MHz, the oscillator is 21MHz. Pixel width is about 95us but I wanted to generate 21MHz exactly so I can have few edges to chose from. I will however implement the phase shifter.

[BrianHG]

Look carefully at your pixel clock scope shots.  It's the rising edge of the cyan colored clock which always grabs the middle sweet spot of a pixel where it's analog vertical height stabilizes.  I'm counting each video element on the screen being 2 pixels wide at 21MHz.  The falling edge of the cyan clock is on the edges of a pixel.  Yet, you wont find out much until you grad the data coming into the cyclone as the inputs have a delayed setup time.  At 15Khz, this means your video coming out has a vertical resolution of something like 1024 pixels, ie 1024x240.  A little odd.  I would have suspected that the true sampling clock was 10.5 MHz making a screen res of 512x240.

Nope, the pixel clock is 10.5MHz, the oscillator is 21MHz. Pixel width is about 95us but I wanted to generate 21MHz exactly so I can have few edges to chose from. I will however implement the phase shifter.

This is what the '4 bit sample phase (now 5 bit)' adjustment is for.  It shifts the 10.5MHz sample clock to 1 of 32 horizontal positions.  Something your 21MHz 2 positions in a 10.5MHz clock cannot do.

As for your latest scope shot, that looks dead perfect.

[BrianHG]

Last scope shot analyzed...


Still very good unless the measurement on the left is something in the codding, but somehow corrects itself afterward.  Make sure you were operating in the DDR mode...

Now in you scope measurements from above with the second PLL, that PLL seemed way too noisy compared to this reference 10.5MHz clock feeding it.  The PLL should have generated a cleaner clock.

Possible fixes:
1. Redo measurements with only 2 channels shown so you see scope samples at 500MS/s so there is less interpolation of missing data.
2. Change the second PLLs bandwidth setting to 'AUTO'.  The low bandwidth setting I recommended was for fixing up a terrible 10.5MHz reference.  Your 10.5MHz seems excellent, using the low bandwidth setting is actually making the PLL output more jittery.

Lets see how you plan to software shift the 10.5MHz reference clock in your soft-PLL code.
If you do not want to do it in your soft-PLL section, I recommend making your second PLL run at 84MHz not 21MHz and sample every 8th pixel while making an adjustment to begin 1 through 8 clocks from the beginning of the h-sync.

Remember, you cannot simultaneously tap that DDIO input from the pin IO on a different clock domain without hindering the soft-PLL's performance.  Within your soft PLL just double or triple register the sync_inh and feed that to an output on your soft-pll code and use that as a new h-sync to control your video sampler section.

[Miti]

Still very good unless the measurement on the left is something in the codding, but somehow corrects itself afterward.  Make sure you were operating in the DDR mode...

How? I thought, since we're using DDIO in and out, we are in DDR mode. I'm sorry for being such a noob but I am...a noob.

Now in you scope measurements from above with the second PLL, that PLL seemed way too noisy compared to this reference 10.5MHz clock feeding it.  The PLL should have generated a cleaner clock.

Possible fixes:
1. Redo measurements with only 2 channels shown so you see scope samples at 500MS/s so there is less interpolation of missing data.
2. Change the second PLLs bandwidth setting to 'AUTO'.  The low bandwidth setting I recommended was for fixing up a terrible 10.5MHz reference.  Your 10.5MHz seems excellent, using the low bandwidth setting is actually making the PLL output more jittery.

Attached.
I did try low, medium and high bandwidth. It doesn't make any difference.

Lets see how you plan to software shift the 10.5MHz reference clock in your soft-PLL code.
If you do not want to do it in your soft-PLL section, I recommend making your second PLL run at 84MHz not 21MHz and sample every 8th pixel while making an adjustment to begin 1 through 8 clocks from the beginning of the h-sync.

I was thinking a 16 bit LPM_SHIFTREG with 336MHz clock and the reset condition "if (!sync_inh && sync_inh_reg) at data input. Then I use a 4 bit register and in a case statement I assign one of the output of the shift register to a wire. Then I use that wire as a condition to
if (wire)
  begin
   counter < 1'b0;
   sync_inl_reg <= sync_inl;
  end
  else...
 

Remember, you cannot simultaneously tap that DDIO input from the pin IO on a different clock domain without hindering the soft-PLL's performance.  Within your soft PLL just double or triple register the sync_inh and feed that to an output on your soft-pll code and use that as a new h-sync to control your video sampler section.

A challenge a day from you Brian...
How do you do that?

[BrianHG]

Ok, in verilog, you do not need to bother with the 'LPM_SHIFT_REG'.

At least not in system verilog, but lI gave it a try.

Here is what your have when feeding the (I'm guessing since you haven posted your latest code...)

Code: [Select]

clk_out_h       <= sync_inl_reg ? counter_dl[4] : counter[4];
clk_out_l       <= counter[4];
Here is what I did:

Code: [Select]

input wire          load_phase,  // make high when loading the new phase
input wire [3:0] phase_in,      //  0 through 15 phase positions
output reg         sync_out       // buffered H-sync output
...........
reg   [3:0] phase_reg;
reg   [31:0] clk_shift_h, clk_shift_l, sync_shift;
..........

if (load_phase) phase_reg <= phase_in;

//clk_out_h       <= sync_inl_reg ? counter_dl[4] : counter[4];  // directly send output clock
//clk_out_l       <= counter[4];
clk_shift_h[0]    <= sync_inl_reg ? counter_dl[4] : counter[4];  // load output clock into beginning of shift register
clk_shift_l[0]    <= counter[4];
clk_shift_h[31:1] <= clk_shift_h[30:0];                 // Shift the shift register
clk_shift_l[31:1] <= clk_shift_l[30:0];
clk_out_h         <= clk_shift_h[phase_reg[3:0]*2];  // use the loaded phase_reg to select every second 0 through 30 taps on the shift register
clk_out_l         <= clk_shift_l[phase_reg[3:0]*2];

sync_out          <= sync_inh_reg;  // pass the sync input to the output.


I tried this code and Quartus reported the FMAX at 256MHz, but you need 336.  So, do not bother adding the phase to the soft-pll code.  Only add the :

Code: [Select]

output reg sync_out
....
sync_out          <= sync_inh_reg;

For your video sampling section, do not tie it's H-sync reference to the h_sync input pin, tie it to this module's 'sync_out' reg.

I would recommend running your sampling code at 84MHz or 168MHz.  Basically configuring your second PLL to give you that frequency from the 10.5MHz.  And when you grab a pixel, grab every 8th or every 16th clock.  Your sample phase will be 3 or 4 bits, selecting which on of the every 8th or 16th clock you take in a pixel.


It should be no more complicated than this (168MHz example):

Code: [Select]

input  wire [3:0] phase_selection,
input  wire set_phase_selection,
output reg  test_sample_point,

.....


reg [3:0] current_phase, phase_selection_reg;

always @ (posedge clk168m) begin

last_sync_in <= h_sync_in;

if (set_phase_selection) phase_selection_reg <= phase_selection;

if ( ~h_sync_in && last_sync_in ) begin                        // H-Sync pulse low has been recieved
                                  current_phase <= 0;          // clear the phase
                                  cord_x        <= 0;          // clear the video raster X coordinate
               if ( ~v_sync_in )  cord_y        <= 0;          // clear the video raster Y coordinate
               else               cord_y        <= cord_y + 1; // increment the raster Y coordinate

end else begin // not an hsync pulse, a video line

    current_phase <= current_phase + 1;

      if (current_phase == phase_selection_reg) begin   // time to sample a pixel

               //write input pixel to dual port ram at cord_x //

               cord_x            <= cord_x + 1;
               test_sample_point <= 1;  // pulse the test sample point
      end else test_sample_point <= 0;  // clear the pulsed test sample point

  end // end of video line

end // always @ posedge

(84MHz is the same except the current_phase & phase_selection will now be 3 bits instead of 4 bits.  The width of the test output pulse will also now be 42MHz instead of 84MHz.)

Making this code now without the ram, just the test_sample_point output feeding an output would reveal a tiny 84Mhz pulse once per pixel which you can move left and right, 16 positions, depending on the 'phase_selection'.

If you need to test and do not currently have an effective way of driving the 'phase_selection' with a number, and your dev board has an rs232 port, you may use my 'SYNC_RS232_UART.v' here:

https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/

You may also use the full RS232_debugger if you want to real-time read 4 byte ports, write 4 byte ports, and address read/write memory.

(warning, some FTDI USB-RS232 converters interfere with Quartus USB Blaster.  You just need to close the COM port before using the programmer & then you can re-open the com port.)

Note, if the test pulse jitters left & right, it's because of the way we are reading and converting the hsync coming in and how the clock is being generated.  The fix will be to make a 10.5MHz output on the second PLL as well as the 168MHz, and in your code, then first latch the sync into a register with an:

always @ (posedge clk10_5) begin
h_sync_clk10_latch <= hsync_in;
end

Then in the main code section, replace the h_sync_in with h_sync_clk10_latch.  This should extra clean up the h_sync.  If not, you may need to change the (posedge clk10_5) to a (negedge clk10_5).

[Miti]

Please keep in mind that I need 55.125MHz as well for the VGA side. The second PLL cannot generate more than 42MHz in this combination. I think I’m okay though, maybe using bit 0 of the selection register to enable/ disable an inverter, this way I can use both rising and falling edges.

[BrianHG]

So just use 42Mhz with 2 bits phase selection, 4 sample points.  + Only if you really need it, a DDIO_in on the video input bits allowing for a selection of when you grab the pixels, on the high or low transition edge of a clock of the 42MHz making a total of 8 sample phases to choose from.

I'm curious, what kind of panel are you using?
Most standard vesa video modes, like 1024x768 has a 65MHz clock, not 55.125MHz.

In fact, looking here: http://tinyvga.com/vga-timing

Code: [Select]

http://tinyvga.com/vga-timing/1024x768@60Hz
I don't see any multiple of 55.125MHz.

LOL, if your scope output 512x256 2 bit color, you have enough ram on the smallest CycloneIV to store an entire frame.
With a standard UART at 921600 baud, you can display around 3fps on a PC without any compression.
Probably around 10fps with dumb RLE compression.

[Miti]

I'm curious, what kind of panel are you using?
Most standard vesa video modes, like 1024x768 has a 65MHz clock, not 55.125MHz.

In fact, looking here: http://tinyvga.com/vga-timing

Code: [Select]

http://tinyvga.com/vga-timing/1024x768@60Hz
I don't see any multiple of 55.125MHz.

LOL, if your scope output 512x256 2 bit color, you have enough ram on the smallest CycloneIV to store an entire frame.
With a standard UART at 921600 baud, you can display around 3fps on a PC without any compression.
Probably around 10fps with dumb RLE compression.

This one:
https://www.aliexpress.com/i/4000282196847.html

I know it is not a standard VGA pixel clock but the panel, and two monitors, have no issues locking onto this pixel rate and auto adjusting the position right in the middle. This is the only frequency that I found to give me a VGA framerate identical to the video framerate, with a little tweak in the front and back porch. This simplifies my buffering a lot. I don't need external double or tipple buffer to avoid flickers.
I also avoid the need for blending with driving the LCD panel directly, as the panel is only 640x480.
The video output is 509?x254 visible if my measurements are correct, so double the pixels and triple the lines, would fit quite nicely into 1024x768 VGA with some spare pixels left and right and lines top and bottom.

Edit: In Reply #10 you can see a picture of the panel showing a test pattern with the exact specs that I mentioned before, including three pixel wide horizontal lines.

[BrianHG]

Ok. No prob.  I assumed you would use the panel at it's native edge to edge and scale the scope's sample image onto it either with a panel which was exact 2x by 3x, or, you would use a lower res panel like 640x480 and do a bi-linear or bi-cubic filtering, or even a sub-pixel scaling.  (IE sup-pixel scaling of a 640x480 LCD panel makes the panel appear to be 1920x480.  (some panels have a special RGB matrix which make their 640x480 sub-pixel mode more like 1280x960) This trick would make 512 pixels, or 509 pixels stretch much more nicely onto 1920 pixels wide without clunky edges.  However, you MUST be feeding the panel at it's native res, otherwise you will get color artifacts when doing this trick wrong.)

[Miti]

Ok, so I implemented the PLL clock, the ADC I2C reader and the IR into the VGA pattern generator. The ADC reads the brightness potentiometer, the IR input is used to select different color schemes. The module will have few color schemes with different colors for low and high brightness to give a bit of color to this old thing.

I then compared the vertical sync pulses of the spectrum analyzer and of the VGA output. Without HSync they drift slightly relative to each other. Once I connected the HSync, they are dead locked as they should be, and the pattern is very stable. I let them run for minutes and there was zero drift. Se attached.

[BrianHG]

Excellent.  Though I don't know the extent of you project, but if you stored the entire source image in the Cyclone DualPort ram, you don't really need the output video locked into the source video.  Your perfect locking is good if you only want to use a single 9kbit block of ram to generate the output image.

Is it just me, or is your video in 49.8Hz and your video out 99.6Hz?
LCD screens wouldn't flicker at 49.8Hz unless you want to drive VGA CRTs.

I assume for the brightness, you will just be assigning 2 contrast levels to the 2 source video levels before sending that to the LCD.

Maybe something with a little optional color, like you stated...

(FPGA tech note:  When defining any type of large memories like dual port or fifos with Cyclone FPGAs, they will round up you chosen memory size to the nearest 9kbits when fitted in the FPGA fabric.  So, if you have a 512x8 line buffer, it will still end up consuming a 1024x9 chunk in the Cyclone block ram.  The undefined region will just be ignored and never used.)

[Miti]

Excellent.  Though I don't know the extent of you project, but if you stored the entire source image in the Cyclone DualPort ram, you don't really need the output video locked into the source video.  Your perfect locking is good if you only want to use a single 9kbit block of ram to generate the output image.

You are right, the reason I wanted to use only half image buffer is to reduce the output lag relative to the input image. Not sure if that is important though.

Is it just me, or is your video in 49.8Hz and your video out 99.6Hz?
LCD screens wouldn't flicker at 49.8Hz unless you want to drive VGA CRTs.

I assume you say that because you don't see the middle pulse in channel 1. Look at the gap in the thick yellow trace. They are both same frequency.
If you read from output port while you write to the input port, the image may blink for a moment. Also, when the output image starts in the middle of the input image due to drift, if there's a dramatic change in the input image, I think it would show. That's the flicker I was talking about.

I assume for the brightness, you will just be assigning 2 contrast levels to the 2 source video levels before sending that to the LCD.

Maybe something with a little optional color...

The input image would have 2 bits. 00 for black, 01 for low brightness and 11 for high brightness. The input from the ADC is a 10 bit value. The VGA output is 0-1023, even though it will be mapped to 16 or 32 output levels, I haven't decided yet. My intention is to multiply the ADC value with bit 0 or bit 1 to get the VGA output value and color according to the color scheme.
There will be 5 - 6 color schemes selected either using an external IR remote, or fixed scheme using jumpers.
There's a hole on the side of the case for focus adjustment in the CRT display that I can use for an IR sensor.

[BrianHG]

I assume you say that because you don't see the middle pulse in channel 1. Look at the gap in the thick yellow trace. They are both same frequency.
If you read from output port while you write to the input port, the image may blink for a moment. Also, when the output image starts in the middle of the input image due to drift, if there's a dramatic change in the input image, I think it would show. That's the flicker I was talking about.

Is this because you cannot retain a perfect H-sync from input to output image?
A delay of your output image by 1 or 2 lines of video should prevent this problem.

When you say blink, what do you mean?
Does the image jump vertically by a line, or a scrolling line jump, or something like that?

Since I don't know how you designed your architecture, I cannot foresee any approach I would use which would cause a blink of any sort.  A delay of 2-3 lines of video, IE a 1/5000 of a sec delay from picture in to picture out is nothing at all.  A delay of even 1 full frame at 1/50th of a second would not be registered or perceived by anyone.

[Miti]

I thought about that right after I posted. The frames should not drift at all if HSync is present, is just that they start in random position relative to each other. Let me give it more thought.

[BrianHG]

I thought about that right after I posted. The frames should not drift at all if HSync is present, is just that they start in random position relative to each other. Let me give it more thought.

Though this is easily solved, it still makes no difference if your picture out is delayed by 2-3 lines of picture.
You would literally have written 2-3 full lines in your 4 line buffer before the first one comes out.

You can also use the hsync coming into the sampler to reset the horizontal position counter of the hsync coming out of your VGA pattern generator.  Or, if you look at my sampler code, you can make an output which pulses at any cord_x number which you can use to reset the output horizontal position of your VGA generator to align it the way you like.  Same with the cord_y counter in my example code.  You can make the your output vsync begin on line 0, 1, 2 or 3 or any vertical position of the source video coming in.

[Miti]

Since we deviated pretty much from the initial PLL subject, I suggest we continue the discussion here:

https://www.eevblog.com/forum/projects/hp-8594e-replacing-the-green-crt-with-lcd/msg3022500/#msg3022500

That project will be the end application of this experiment plus these ones:

https://www.eevblog.com/forum/fpga/converting-a-two-level-analog-signal-to-two-bits-digital-in-cyclone-iv-orand-v/
https://www.eevblog.com/forum/fpga/adc-in-altera-cyclone-fpga/                    which I will finalize one day using your code with shift registers.

[Miti]

In my designs, I usually fast input & fast output register all IOs in my designs at the minor possible cost of reaching an FMAX.

I assume digital IOs? I don't think it makes sense assigning fast IO registers to LVDS IOs.

[BrianHG]

In my designs, I usually fast input & fast output register all IOs in my designs at the minor possible cost of reaching an FMAX.

I assume digital IOs? I don't think it makes sense assigning fast IO registers to LVDS IOs.

Just go ahead.
Don't worry about FMAX, it's not like you have filled the FPGA to 98% logic registers full and you are trying to achieve an FMAX of 200MHz for the entire chip.

The fast in&out just directs the fitter where to optimize the location of the register D-flipflop on the FPGA fabric.  Locating the flipflop closest to the IO if that flipflop is the one generating an output, or reading an input just makes that associated IO pin have the tightest possible timing.

Using a flipflop on the right hand side of the fpga to drive an IO pin on the left hand side of the fpga might mean an internal better FMAX, but, that IO pin will probably have a huge delay before that data becomes valid.  Now unless you are willing to learn about defining the setup&hold times and constrained paths for IO pins, the fast IO is a cheap trick to tell to compiler to prioritize the IO pin's performance.