Electronics > Projects, Designs, and Technical Stuff
Modern equivalent of 74HC4046 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:
--- Quote from: BrianHG on July 19, 2020, 03:24:31 am ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version