Low input frequency (1MHz) multiplication via PLL

[deanclaxton]

I'm looking to use an FPGA for an upcoming project (my first FPGA project), and am curious about the PLL features. I will have a 1.027MHz clock input that I would like to be able to scale up by 1 to 14x. In theory the PLL resources seem ideal for this (I'm looking at Lattice ICE40 or MachXO2 at this stage since they appear to be well priced) however from the datasheet it appears that they can't handle such a low input frequency. This seems to be common with other standalone PLL clock buffer/multiplier solutions also - many have a minimum input frequency of 2MHz and a minimum output frequency of 10MHz.

In the case of MachXO2 the minimum input frequency is 7MHz, but it can actually divide down into the 10KHz range which is pretty neat.

So it seems that I probably need to use an external oscillator that is 14.3818MHz, and divide that down for my clock, but I'd like to phase match the divided output with the original 1.027MHz clock.

Or is there a better way to approach this? I have yet to decide on the actual FPGA I'll use, so don't yet have a dev board to test myself if it will work via the PLLs.

If anyone has any experience with this I'd be grateful for any advice that can be offered.

Cheers,
Dean

[KrudyZ]

Yes this is a rather annoying limitation.
What you could do if you have a fixed input frequency is to start with a higher clock rate and then divide that down to the same or close enough frequency and do a phase comparison. The MACHXO2 has a feature to phase shift its VCO, so you can lock onto a reference if it's within a reasonable range. The resulting clock will have some significant jitter though which you can improve on by running it through a second PLL

[BrianHG]

So it seems that I probably need to use an external oscillator that is 14.3818MHz, and divide that down for my clock, but I'd like to phase match the divided output with the original 1.027MHz clock.

We have done this trick before in an Altera Cyclone by running 1 PLL from a reference, IE 14.31818MHz, bumping it up to a high frequency, IE 14.31818MHz * 32 = 458.18176MHz, then use normal gates to divide down and logically PLL lock onto your 1.027MHz.  Or in our case, it was a 15KHz H-Sync from a video signal which we needed to lock onto for video grabbing to create a new pixel clock.  We took the logic clock output and feed it to the second PLL just to make a new extra clean video clock & to run logic in the FPGA.

The source is somewhere here on EEVBlog, but in the projects section...

[Miti]

Here it is

https://www.eevblog.com/forum/projects/modern-equivalent-of-74hc4046-pll/

[deanclaxton]

Awesome - I'll look into this further and pick up a MachXO2 dev board to play around with. ICE40 is a contender also, though it doesnt support the low output frequencies on the PLL's so perhaps MachXO2 is the way to go for now. Although it seems that rather than using the PLL to divide down, Id be using gates. I can experiment with both approaches. Its the phase lock I'll have to work out - will do some reading

[BrianHG]

The theory I made when telling Miti how to make his PLL as follows.

Take your desired output clock.
Multiply by a factor of 2^x  -> 16/32/64/128 until you max out the FPGA and use that figure as your target frequency.  IE, 1.027*256 = 262.912.  (The higher this frequency, the better the quality of the output.  In Miti's 74HC4060 thread, we actually used a trick with the FPGA's DDRIO function to further get double the precision.)  (This precision is phase noise relative to your source.  The PLL output frequency is exact...)

Find a source crystal oscillator which you can feed the FPGA PLL which can be set exactly to 262.912MHz.

Make a divide by 256 counter with a synchronous reset.

2 layer latch your 1.027MHz reference coming into an input and reset the divide by 256 counter on a low to high transition between the 2 input latches.  The output of the divide by 256 counter should be locked onto the 1.027MHz input.

This does not directly solve your intermediate frequencies you want from the 1.027MHz other than the x2,x4,x8,x16,x32 (the lower bits going up your 256x counter).  But this may be a basis to use, for example the x16 output and you feed a second PLL (optional) and logic counter divide that down in fractions to get all you want.

[deanclaxton]

Thanks Brian - that explains it nicely x2, x4 , x8 may well be enough choice for the output clock anyway. I'll pick up a dev board and have a play around with this - will have a look at available crystal frequencies.

EDIT: Ordered the MachX02 Breakout board!

[KrudyZ]

I would really recommend you look into the phase shift capabilities of the MACHXO2 VCO as it allows not just phase lock, but phase lock over a certain frequency range only limited by the update rate of the phase shift logic.
Your reference clock and the clock you are trying to lock on to will never be stable relative to one another unless they are actually derived from the same source, in which case the exercise is kindo pointless. You therefore need to be able to track frequency deviations as well.
With the suggested method of resetting a divide by 256 counter, you will sometimes do it at 255, sometimes at 256 and sometimes at 257. This generates some pretty nasty jumps in particular if you want to use the lower order bits of the counter.
Using the VCO phase advance / retard capabilities of the MACHXO2 adds or subtracts a 45 degree shift in the VCO output which is running at 400 - 800 MHz. Once you divide that down the phase jumps will be really small by comparison.

[deanclaxton]

I would really recommend you look into the phase shift capabilities of the MACHXO2 VCO as it allows not just phase lock, but phase lock over a certain frequency range only limited by the update rate of the phase shift logic.
Your reference clock and the clock you are trying to lock on to will never be stable relative to one another unless they are actually derived from the same source, in which case the exercise is kindo pointless. You therefore need to be able to track frequency deviations as well.
With the suggested method of resetting a divide by 256 counter, you will sometimes do it at 255, sometimes at 256 and sometimes at 257. This generates some pretty nasty jumps in particular if you want to use the lower order bits of the counter.
Using the VCO phase advance / retard capabilities of the MACHXO2 adds or subtracts a 45 degree shift in the VCO output which is running at 400 - 800 MHz. Once you divide that down the phase jumps will be really small by comparison.

Ok cool - so use a reference clock a multiple of the target, and use the PLL to divide down since the MachXO2 can actually divide right down into the 10kHz range provided the input is > 7MHz. So Id divide down to get 1MHz, 2MHz etc. Can it then sync the phase with the original 1MHz reference clock, or would I use the phase sync method suggested by Brian? The family datasheet suggests that the minimum input frequency for the phase detector is 7MHz, but I'm unsure it that is just talking about our clock before we divide it down. I need to really study the docs to understand how this all works.

Took a look at oscillators - 171.8182MHz seems to be commonly available (14.31818MHz * 12) but 315MHz is also available which is 14.31818MHz x 22 - could be a winner. MachXO2 supports max 400MHz clock input from what I've read (the 1 MHz reference is 1/14th of 14.3181818 = approx 1.027MHz).

[KrudyZ]

The way to do this is to use the clock from the PLL block to sample the clock signal you want to lock onto.
If the sampling clock is nominally x times faster than your input frequency, then you expect a low to high transition every x number of samples.
You then see if the edge occurred early or late and adjust the PLL clock by phase shifting its VCO to servo the sampling clock to sample exactly on the edge.
If the edge is early, i.e. there are only x-1 samples between edges, then you need to increase the VCO speed and if it is late then you slow it down.
You likely want to add some digital filter to limit the adjustment frequency and reduce jitter.
You need to make sure that the clocks are close enough to allow capture with the maximum phase adjust, i.e. added frequency, your design allows.
For example, if the VCO is set to 500 MHz and you allow a maximum phase shift update frequency of 1 MHz then the PLL will be shifted up or down by a maximum of 125 kHz, since each phase step is 45 degrees. That means you have a range of +- 250ppm that the clocks can be off from nominal and still achieve lock.
This method works really well, I have used it in many designs.

[BrianHG]

I would really recommend you look into the phase shift capabilities of the MACHXO2 VCO as it allows not just phase lock, but phase lock over a certain frequency range only limited by the update rate of the phase shift logic.
Your reference clock and the clock you are trying to lock on to will never be stable relative to one another unless they are actually derived from the same source, in which case the exercise is kindo pointless. You therefore need to be able to track frequency deviations as well.
With the suggested method of resetting a divide by 256 counter, you will sometimes do it at 255, sometimes at 256 and sometimes at 257. This generates some pretty nasty jumps in particular if you want to use the lower order bits of the counter.
Using the VCO phase advance / retard capabilities of the MACHXO2 adds or subtracts a 45 degree shift in the VCO output which is running at 400 - 800 MHz. Once you divide that down the phase jumps will be really small by comparison.

Those jumps in my counter only occasionally happen, usually only 1 direction, whether is be adding or subtracting 1 clock cycle with the source clock frequency.  So, running your PLL to a target of 512*1.027 = 525.824MHz, so 1 step is ~1.95ns.  Using the DDR trick in Miti's thread, then you get an occasional <1ns step.  Feeding that output through a second PLL, whether 1 or 2ns step, if that second PLL's loop bandwidth is below 1MHz (the reference clock frequency), then the 1-2ns occasional steps will be filtered/averaged out.

[BrianHG]

@deanclaxton, where did you get that 1.027MHz from.  Is it some old crystal clock?  Or, did you measure the frequency with a scope, or a frequency counter?

Also, if any of those FPGA's can lock onto 2.054MHz directly, with 2 additional inputs, and an inductor/cap/resistor, you can double the 1.027MHz using an async XOR gate programmed into the FPGA.

[asmi]

I would just use a programmable MEMS clock generator. If you don't want to invest into programmer, you can order them at Digikey, and they will program them for you as a value-added service. Or, if you need a lot of them, you can contact the likes of SiTime and they will factory-program whatever amount you need.
Or you can use reprogrammable generators and configure them on the fly. This is probably going to be more expensive than pre-programmed parts, but it's more flexible.

[vk6zgo]

You could do it "old school" & using frequency multiplier stages, (LC resonant circuits turned to a harmonic of the original frequency), multiply  the "around 1MHz" up to "around 10MHZ", then use that for your reference.

This is just as legitimate an approach as "dividing down" from a higher frequency, & was the method of choice for obtaining higher frequencies prior to, & for a lot of years after, the advent of the PLL.

[deanclaxton]

@deanclaxton, where did you get that 1.027MHz from.  Is it some old crystal clock?  Or, did you measure the frequency with a scope, or a frequency counter?

Also, if any of those FPGA's can lock onto 2.054MHz directly, with 2 additional inputs, and an inductor/cap/resistor, you can double the 1.027MHz using an async XOR gate programmed into the FPGA.

System is an Apple ][ computer, and I'm working on an accelerator with some other features including ROMX functionality (theromexchange.com). The the machine uses a 14.31818MHz reference, that is divided down by 14 to create the CPU clock. NTSC units use that reference anyway - PAL units are slightly different which is why I'd love to be able to do this without an external reference oscillator as I'd possible have to produce the board with 2 different crystals. Perhaps the reprogrammable MEMs oscillators could work for this though.

I'm waiting for the MachXO2 board to arrive and I'll then cobble together a test system

[BrianHG]

@deanclaxton, where did you get that 1.027MHz from.  Is it some old crystal clock?  Or, did you measure the frequency with a scope, or a frequency counter?

Also, if any of those FPGA's can lock onto 2.054MHz directly, with 2 additional inputs, and an inductor/cap/resistor, you can double the 1.027MHz using an async XOR gate programmed into the FPGA.

System is an Apple ][ computer, and I'm working on an accelerator with some other features including ROMX functionality (theromexchange.com). The the machine uses a 14.31818MHz reference, that is divided down by 14 to create the CPU clock. NTSC units use that reference anyway - PAL units are slightly different which is why I'd love to be able to do this without an external reference oscillator as I'd possible have to produce the board with 2 different crystals. Perhaps the reprogrammable MEMs oscillators could work for this though.

I'm waiting for the MachXO2 board to arrive and I'll then cobble together a test system

Why didn't you say so... 1.027 is not the frequency by a mile.  This is why I cannot figure out what you were trying to achieve.   The real frequency is 1.022727271 MHz.....

NTSC and PAL do have a common thread frequency which you can PLL divide perfectly between the two.  It is 27MHz.

The conversion factor is x35/66.  27.0000 * 35/66 = dead perfect 4x NTSC color burst frequency.
I don't remember the PAL factors, but they are also a perfect small integer multiply/divide.

This is why once digital broadcast TV came about, the Analog encoder/decoders used 27MHz crystals so they may support NTSC & PAL with the same clock source.

Now, 35/66 might not be possible with all FPGA PLLs as the numbers are sorta large, however from experience, Altera PLLs can handle it.

In fact, 27x10, 270MHz source clock, divide that by 264 exact and you get 1.02272727MHz exact...

[deanclaxton]

@deanclaxton, where did you get that 1.027MHz from.  Is it some old crystal clock?  Or, did you measure the frequency with a scope, or a frequency counter?

Also, if any of those FPGA's can lock onto 2.054MHz directly, with 2 additional inputs, and an inductor/cap/resistor, you can double the 1.027MHz using an async XOR gate programmed into the FPGA.

System is an Apple ][ computer, and I'm working on an accelerator with some other features including ROMX functionality (theromexchange.com). The the machine uses a 14.31818MHz reference, that is divided down by 14 to create the CPU clock. NTSC units use that reference anyway - PAL units are slightly different which is why I'd love to be able to do this without an external reference oscillator as I'd possible have to produce the board with 2 different crystals. Perhaps the reprogrammable MEMs oscillators could work for this though.

I'm waiting for the MachXO2 board to arrive and I'll then cobble together a test system

Why didn't you say so... 1.027 is not the frequency by a mile.  This is why I cannot figure out what you were trying to achieve.   The real frequency is 1.022727271 MHz.....

NTSC and PAL do have a common thread frequency which you can PLL divide perfectly between the two.  It is 27MHz.

The conversion factor is x35/66.  27.0000 * 35/66 = dead perfect 4x NTSC color burst frequency.
I don't remember the PAL factors, but they are also a perfect small integer multiply/divide.

This is why once digital broadcast TV came about, the Analog encoder/decoders used 27MHz crystals so they may support NTSC & PAL with the same clock source.

Now, 35/66 might not be possible with all FPGA PLLs as the numbers are sorta large, however from experience, Altera PLLs can handle it.

In fact, 27x10, 270MHz source clock, divide that by 264 exact and you get 1.02272727MHz exact...

ah yes - doh! 1.02272727 - thats what I need. 27MHz - nice - multiply x 10, divide by 264 - excellent I'll definitely look into that a bit more with the PAL side of things. So the source clock on the motherboard will be running at 1.0227 MHz, and my cpu will be running much faster but synching certain data with the logic on the motherboard. Early days with just a half baked conceptual layout at this stage - FPGA kit should arrive during the week. Previously Id been using using WinCUPL with the Microchip AFT150x CPLD's so will now learn Verilog

[BrianHG]

Almost everything in the computer, including some > > peripherals like the floppy controller, are carefully designed ... All the standard Apple II clock frequencies are derived from this. ... (For PAL models, it is 14.25 MHz / 14 = 1.0178571429.

Google is your friend... 'pal apple II computer clock frequency'

Switch to 13.5MHz, IE 27MHz/2.  Still a standard, or some PLLs allow you to divide your source clock by 2.

For NTSC, x20, divide by 264 = 1.02272727 MHz perfect.
For NTSC, x35, divide by 462 = 1.02272727 MHz perfect.
For PAL,   x19, divide by 252 = 1.0178571429 MHz perfect

Or,
For NTSC x35, divide by 33 = 14.3181818181818181... MHz perfect.
For PAL,   x19, divide by 18 = 14.25 MHz perfect.