The vcocalc.py supplied with the SDK suggests that 12.288 can't be achieved directly, within the permitted PLL parameters. In particular, the minimum VCO frequency is 750MHz, and the maximum output divider is /49, so the slowest clock you can get out of the PLL is 15.3MHz.
You can achieve 61.44 MHz (12.288 *5) in the PLL, and then use divide-by-5 in the GPCLKOUT to generate 12.288; by default that gives you an asymmetric clock, but you can enable the duty-cycle correction to make it symmetric (at the cost of extra jitter).
That then leaves you with one PLL running at a silly frequency that's not suitable for either the CPU or the USB, and only one PLL left to generate those two clocks.
You could perhaps run CPU at 96MHz and get the USB clock with a divide-by-2, or go for a mild overclock to CPU at 144MHz and USB via divide-by-3. I'm not really convinced this is a great idea. Maybe it would be OK if you don't need USB and audio at the same time.
I've fiddled with the numbers by hand in case there was something vcocalc was missing, but it's fairly fundamental.
12288 = 1024*12, but we need that divided by 1000, so:
1024 * 12 / 1000 = 128 * 12 / (5 * 5 * 5), or as prime factors 2^9 * 3 / (5^3)
The PLL can multiply the input clock by any number we like (keeping in the 750MHz-1600MHz range), but to divide it down afterwards we have only two dividers in the range 1-7. So that's what gives us the 16.44MHz that vcocalc came up with - put 5 into both of the PLL dividers and the other 5 in the GPCLKOUT divider. With those numbers, the VCO is running at 12.288*5*5*5 = 1536MHz, so we can't afford to go any higher to give a more useful clock for the CPU.
There is one further configuration variable - the input clock can be divided before the PLL multiplies it, but with a minimum of 5MHz. So we'd love to put one of our factors of 5 in there, but we can't as 12/5 = 2.4MHz, too slow. In fact with a 12MHz xtal, the only legal value we can put in there (apart from 1) is 2, and that's no help at all as we are already multiplying by a power of 2.
You can achieve 61.44 MHz (12.288 *5) in the PLL, and then use divide-by-5 in the GPCLKOUT to generate 12.288; by default that gives you an asymmetric clock, but you can enable the duty-cycle correction to make it symmetric (at the cost of extra jitter).
That then leaves you with one PLL running at a silly frequency that's not suitable for either the CPU or the USB, and only one PLL left to generate those two clocks.
You could perhaps run CPU at 96MHz and get the USB clock with a divide-by-2, or go for a mild overclock to CPU at 144MHz and USB via divide-by-3. I'm not really convinced this is a great idea. Maybe it would be OK if you don't need USB and audio at the same time.
I've fiddled with the numbers by hand in case there was something vcocalc was missing, but it's fairly fundamental.
12288 = 1024*12, but we need that divided by 1000, so:
1024 * 12 / 1000 = 128 * 12 / (5 * 5 * 5), or as prime factors 2^9 * 3 / (5^3)
The PLL can multiply the input clock by any number we like (keeping in the 750MHz-1600MHz range), but to divide it down afterwards we have only two dividers in the range 1-7. So that's what gives us the 16.44MHz that vcocalc came up with - put 5 into both of the PLL dividers and the other 5 in the GPCLKOUT divider. With those numbers, the VCO is running at 12.288*5*5*5 = 1536MHz, so we can't afford to go any higher to give a more useful clock for the CPU.
There is one further configuration variable - the input clock can be divided before the PLL multiplies it, but with a minimum of 5MHz. So we'd love to put one of our factors of 5 in there, but we can't as 12/5 = 2.4MHz, too slow. In fact with a 12MHz xtal, the only legal value we can put in there (apart from 1) is 2, and that's no help at all as we are already multiplying by a power of 2.
Statistics: Posted by arg001 — Tue Jul 16, 2024 2:49 pm