You should be using DAC mode %10111. That's a 75-ohm 2.0V DAC that drops to 1.0V when connected to a monitor that provides 75-ohms-to-ground termination.
The HSYNC signal, on the other hand, should use DAC mode %10110 fot 3.3V output.
dacmode_s long %0000_0000_000_1011000000000_01_00000_0 'hsync is 123-ohm, 3.3V
dacmode_c long %0000_0000_000_1011100000000_01_00000_0 'R/G/B are 75-ohm, 2.0V
XDIV=1, XMUL=7 also looks good. Monitor says 57 Hz. Looks good on scope too.
So, XDIV decides the PLL frequency, right? What is the allowable range?
I XMUL multiplies this to give VCO frequency that should be between 100 and 300 MHz.
BTW: I don't see the utility of the XDIVP when VCO is limited to 100 to 300 MHz... Am I missing something? Maybe for low power standby?
Close, XDIV does not directly set VCO, it sets the Phase Frequency Detector Frequency, and then the loop locks so that
PFD = Xtal/XDIV = VCP/XMUL
SysCLK =- VCO/XDIVP
The highest value for XDIV is 64, which can give a PFD of 312.5kHz, but your tests suggest 0.5MHz is too low for acceptable jitter, & 666kHz is marginal.
A lower PFD updates the charge pump less often, and the slower rate means less noise cancelling allowing the VCO to drift/jitter more.
- however, a lower XDIV reduces the choices, and gives higher errors in the final SysCLK, so it is a compromise for any given Xtal value between jitter and ppm....
It may be that 144MHz is a USB friendly, compromise choice for VGA ?
Even 148.5 is not random for USB, it locks at a 1.5MHz rate, so every 8 USB periods, is 99 SysCLKs.
I'm thinking of ways to graph the VCO jitter vs PFD, but I think it needs external hardware.
A 74HC4046 PLL phase comparator, should be able to connect directly to XO and a Pin generating SysCLK/(XMUL/XDIV) = Xtal Freq.
The low pass info of that XOR mixer, should be audible/measurable as the spectrum of the jitter.
On the P2 Eval board, this test can run at 160MHz, which might be good enough.
If you have XDIV=1, XMUL=7 working, (any missing pixels?) maybe it can also be tested at 140MHz
The other issue is ghosting...
Can really see it with black chars on white background.
Interesting, quite a delay, but a nice copy....
If that delay is 6 pixels, that's about 40ns, which equates to a cable round trip equivalent of ~8m - how long is your cable ?
Jmg, you could put a capacitor on a pin, and then set it for Schmitt feedback mode, forming an oscillator. Use the smart pin to measure rises against a number of system clocks. Then, you'd have some relative measurement that jitter could be determined from.
Jmg, you could put a capacitor on a pin, and then set it for Schmitt feedback mode, forming an oscillator. Use the smart pin to measure rises against a number of system clocks. Then, you'd have some relative measurement that jitter could be determined from.
I'm not following, the jitter on any RC-Osc is far worse than what we are trying to see on the VCO ? eg I measure RCFAST jitter at just under 0.1%
Jmg, you could put a capacitor on a pin, and then set it for Schmitt feedback mode, forming an oscillator. Use the smart pin to measure rises against a number of system clocks. Then, you'd have some relative measurement that jitter could be determined from.
I'm not following, the jitter on any RC-Osc is far worse than what we are trying to see on the VCO ? eg I measure RCFAST jitter at just under 0.1%
With enough C, I bet it would be relatively stable enough to see PLL jitter with. Try a 1nF cap to ground with 15k-ohm drive.
XDIV=1, XMUL=7 also looks good. Monitor says 57 Hz. Looks good on scope too.
....
XDIV=2, XMUL=15 also looks good. Monitor says 61 Hz.
XDIV=3, XMUL=20 also looks OK, like the above. Monitor says 54 Hz. But, I think I do actually see some imperfections in the display when it is close to all white. Not horrible though.
With these quite wide variations, is the Monitor smart enough to keep 1920 pixels displayed, and all pixels the same width ?
140MHz, 150MHz, 133.3MHz are quite some percent variations. (6.07%, 0.99%, 11.38%)
Maybe a LC based VCO can lock over enough range, and sample 1920 times - impressive if they can do this.
Thinking some more about jitter, visible effects and PFD updates, I added another number ...
The 2nd column is the percentage error, and the PFD/LineScan is the number of PLL updates for each line.
A number here that is not whole, will likely shimmer more than a whole number does.
We know /40 is not great, can you try /37, to see if 0.1% error, but with an exact lock of PFD/LineScan (8:1) is better/worse/no different ?
Others to try would be /27,
Here's a screenshot showing the banding with XDIV=3 and XMUL=20.
It's slight but annoying...
Not there with XDIV=15 and XMUL=111
Checking the power supplies, I find
Core :
SMPS 1.283MHz at 160MHz, so at 148.5MHz that is appx 118 pixels, or the ripple will be ~16 bands across the screen ( but likely not locked ?)
Vio : On the 3v3 side, it like like > ~ 100mA fixed load (33 ohms is ok) is needed to have the SMPS avoid skipping effects.
How many bands of white modulation do you see ? Does adding 33R to 3v3 change it at all ?
The _XDIVP apart from hopefully divide by 2 unless overclocking when it needs to be 1, is useful when running the P2 quite slow.
I did find that using _XDIV (not _XDIVP) to yield 0.5MHz and then multiplying up caused jitter or shimmering whereas 3.0MHz worked fine. It is a shame as dividing any crystal to a common 0.5MHz would have been nice.
It's still stable after running overnight with XDIV=15 and XMUL=111.
With the new porch settings, I'm curious about what works and what does not. ie it's not clear if 15,111 is ok and 10,74 is not, as both give 148MHz ?
Perhaps that means there are 'good' and 'bad' PFD areas, rather than the expected faster is better ?
It does seem that ppm = -3378 is sync-tolerated, (do 1920 pixels still display?) so maybe +480ppm is also ok ? (or is tolerance skewed more -ppm ?)
If 1920 pixels do not fit at 148MHz, a similar PFD setting is XDIV=13; XMUL=193; XDIVP = 2 for PFD = 1.538M & ppm = -259.0673
One pixel at 1920 scan, is 520ppm.
Table of test candidates 20MHz Xtal, 148.5MHz target SysCLK
I could check these on a spectrum analyzer later. From what I've seen so far I would avoid dividers 3-8. 10 is far better than 8. Note that I was adjusting XDIV and XMUL at the same time to keep the output constant. The PLL had a very bad reaction to XDIV=14. XDIV=7 had very bad spurs.
The PFD seems fine at 20MHz. It would be interesting to drive the P2 with an 80+MHz crystal oscillator to see what happens. For RF applications I'd want to use the highest frequency possible, or just bypass the PLL altogether.
It's labor intensive to process these images for the forum. I should see if the analyzer can save screenshots to its floppy drive. Or I could see if any of my SDRs are clean enough to measure the noise.
...
It's labor intensive to process these images for the forum.
I'm curious the file names suggest 160MHz but the spectrum says 87.7 peak ?
The plots also seem to have varying widths, making A-B compare more difficult.
I've found the jitter varies as the part warms up, I suspect there are 'jump-to' and 'jump-away' bumps in the VCO transfer curve, and as the device warms, it is sweeping the control voltage.
...
It's labor intensive to process these images for the forum.
I'm curious the file names suggest 160MHz but the spectrum says 87.7 peak ?
The plots also seem to have varying widths, making A-B compare more difficult.
I've found the jitter varies as the part warms up, I suspect there are 'jump-to' and 'jump-away' bumps in the VCO transfer curve, and as the device warms, it is sweeping the control voltage.
For these plots I was operating the P2 at a fixed 80MHz, with post-divide=2. So 160MHz VCO.
I forgot to mention that I was testing the Goertzel mode output, possibly for an FM transmitter. That makes it comparable to the measurements I took for the P1. The direct digital synthesis method can process arbitrary frequency conversions. The phase noise is worse at higher frequencies. While I was taking PLL measurements at a fixed VCO frequency, I was also doing tests varying the VCO frequency. I used the Goertzel mode to generate 87.7 for my measurements so I wouldn't have to correct for the natural increase at higher frequencies when looking at the plots.
The PFD seems fine at 20MHz. It would be interesting to drive the P2 with an 80+MHz crystal oscillator to see what happens.
Hopefully, PFD continues to work to > 100MHz.
At some point the Xtal amplifier will lose gain, but 48~52MHz clipped sine might be inside scope, and 100M+ at CMOS drive ?
For RF applications I'd want to use the highest frequency possible, or just bypass the PLL altogether.
I'm also studying i2c Oscillator parts, and Si5351A is low cost (~85c/1k), with external Xtal, and new premium parts like Si549 ($8.36/10k) XO, in 5x3.2 are another step-up.
A quick table
Si549.C is P2 useful, notice the much higher VCO, and Xtal, than Si5351A ( or P2), so there are external solutions/workarounds for Premium Frequency use.
VCTCXO seem to be cheap and low power up to 48~52MHz (clipped sine), and available with higher prices and Icc jumps above 52MHz.
Above 100MHz, they tend to be LVDS/PECL etc
Here is my latest streamer logic analyser. It runs on P2D2 at 148.5MHz and P2-ES at 145MHz, both at 1920x1080 VGA.
Attached are both P2D2 and the P2-ES versions.
The streamer is logging 20,000 8bit samples from P56-P63 at the clock frequency. I have a little routine that is outputting incrementing counts to P56-61 which is then displayed on the VGA monitor. Here is a pic with closeup insert. The smallest clocks are 2 clocks (2 pixels) wide.
I will be using this to scope my SD ROM Driver timing
Here is my latest streamer logic analyser. It runs on P2D2 at 148.5MHz and P2-ES at 145MHz, both at 1920x1080 VGA.
Attached are both P2D2 and the P2-ES versions.
The streamer is logging 20,000 8bit samples from P56-P63 at the clock frequency. I have a little routine that is outputting incrementing counts to P56-61 which is then displayed on the VGA monitor. Here is a pic with closeup insert. The smallest clocks are 2 clocks (2 pixels) wide.
I will be using this to scope my SD ROM Driver timing
Very nice. Now if only we could fit that into the ROM
Here is my latest streamer logic analyser. It runs on P2D2 at 148.5MHz and P2-ES at 145MHz, both at 1920x1080 VGA.
Attached are both P2D2 and the P2-ES versions.
The streamer is logging 20,000 8bit samples from P56-P63 at the clock frequency. I have a little routine that is outputting incrementing counts to P56-61 which is then displayed on the VGA monitor. Here is a pic with closeup insert. The smallest clocks are 2 clocks (2 pixels) wide.
I will be using this to scope my SD ROM Driver timing
Very nice. Now if only we could fit that into the ROM
Actually it’s not that large. Without buffers, maybe 1KB ???
Comments
I'm seeing some wavering in the white level in horizontal bands and also some ghosting of characters (now that I have the font there.).
It's slight but annoying...
Not there with XDIV=15 and XMUL=111
Can really see it with black chars on white background.
Maybe we need termination resistors? Nope, added 120 Ohm pull downs on three color lines and it didn't help.
Increasing intensity gets rid of ghosting with white background, but it does it by saturation, not really fixing it...
The HSYNC signal, on the other hand, should use DAC mode %10110 fot 3.3V output.
PFD = Xtal/XDIV = VCP/XMUL
SysCLK =- VCO/XDIVP
The highest value for XDIV is 64, which can give a PFD of 312.5kHz, but your tests suggest 0.5MHz is too low for acceptable jitter, & 666kHz is marginal.
A lower PFD updates the charge pump less often, and the slower rate means less noise cancelling allowing the VCO to drift/jitter more.
- however, a lower XDIV reduces the choices, and gives higher errors in the final SysCLK, so it is a compromise for any given Xtal value between jitter and ppm....
It may be that 144MHz is a USB friendly, compromise choice for VGA ?
Even 148.5 is not random for USB, it locks at a 1.5MHz rate, so every 8 USB periods, is 99 SysCLKs.
I'm thinking of ways to graph the VCO jitter vs PFD, but I think it needs external hardware.
A 74HC4046 PLL phase comparator, should be able to connect directly to XO and a Pin generating SysCLK/(XMUL/XDIV) = Xtal Freq.
The low pass info of that XOR mixer, should be audible/measurable as the spectrum of the jitter.
On the P2 Eval board, this test can run at 160MHz, which might be good enough.
If you have XDIV=1, XMUL=7 working, (any missing pixels?) maybe it can also be tested at 140MHz
If that delay is 6 pixels, that's about 40ns, which equates to a cable round trip equivalent of ~8m - how long is your cable ?
If that is cable effects, you could try low value series R, which would help if Monitor was not ideal, and P2 drive was slightly too low.
Strange. looking more closely at the image, there are 2 ghosts, one 1 pixel delayed so appears as a drop shadow, and another 6 pixels delayed.
Does it get steadily worse ?
I'm not following, the jitter on any RC-Osc is far worse than what we are trying to see on the VCO ? eg I measure RCFAST jitter at just under 0.1%
With enough C, I bet it would be relatively stable enough to see PLL jitter with. Try a 1nF cap to ground with 15k-ohm drive.
Don't see any difference, other than gets hair darker...
Hopefully, just my cabling...
With these quite wide variations, is the Monitor smart enough to keep 1920 pixels displayed, and all pixels the same width ?
140MHz, 150MHz, 133.3MHz are quite some percent variations. (6.07%, 0.99%, 11.38%)
Maybe a LC based VCO can lock over enough range, and sample 1920 times - impressive if they can do this.
Thinking some more about jitter, visible effects and PFD updates, I added another number ...
The 2nd column is the percentage error, and the PFD/LineScan is the number of PLL updates for each line.
A number here that is not whole, will likely shimmer more than a whole number does.
We know /40 is not great, can you try /37, to see if 0.1% error, but with an exact lock of PFD/LineScan (8:1) is better/worse/no different ?
Others to try would be /27,
Checking the power supplies, I find
Core :
SMPS 1.283MHz at 160MHz, so at 148.5MHz that is appx 118 pixels, or the ripple will be ~16 bands across the screen ( but likely not locked ?)
Vio : On the 3v3 side, it like like > ~ 100mA fixed load (33 ohms is ok) is needed to have the SMPS avoid skipping effects.
How many bands of white modulation do you see ? Does adding 33R to 3v3 change it at all ?
I did find that using _XDIV (not _XDIVP) to yield 0.5MHz and then multiplying up caused jitter or shimmering whereas 3.0MHz worked fine. It is a shame as dividing any crystal to a common 0.5MHz would have been nice.
The divisions and multipliers give us lots of combinations.
Ok, changing the V0007 power jumper from VIO to 3V3 does fix this banding issue.
I could check these on a spectrum analyzer later. From what I've seen so far I would avoid dividers 3-8. 10 is far better than 8. Note that I was adjusting XDIV and XMUL at the same time to keep the output constant. The PLL had a very bad reaction to XDIV=14. XDIV=7 had very bad spurs.
The PFD seems fine at 20MHz. It would be interesting to drive the P2 with an 80+MHz crystal oscillator to see what happens. For RF applications I'd want to use the highest frequency possible, or just bypass the PLL altogether.
It's labor intensive to process these images for the forum. I should see if the analyzer can save screenshots to its floppy drive. Or I could see if any of my SDRs are clean enough to measure the noise.
The plots also seem to have varying widths, making A-B compare more difficult.
I've found the jitter varies as the part warms up, I suspect there are 'jump-to' and 'jump-away' bumps in the VCO transfer curve, and as the device warms, it is sweeping the control voltage.
I forgot to mention that I was testing the Goertzel mode output, possibly for an FM transmitter. That makes it comparable to the measurements I took for the P1. The direct digital synthesis method can process arbitrary frequency conversions. The phase noise is worse at higher frequencies. While I was taking PLL measurements at a fixed VCO frequency, I was also doing tests varying the VCO frequency. I used the Goertzel mode to generate 87.7 for my measurements so I wouldn't have to correct for the natural increase at higher frequencies when looking at the plots.
Hopefully, PFD continues to work to > 100MHz.
At some point the Xtal amplifier will lose gain, but 48~52MHz clipped sine might be inside scope, and 100M+ at CMOS drive ?
I'm also studying i2c Oscillator parts, and Si5351A is low cost (~85c/1k), with external Xtal, and new premium parts like Si549 ($8.36/10k) XO, in 5x3.2 are another step-up.
A quick table
Si549.C is P2 useful, notice the much higher VCO, and Xtal, than Si5351A ( or P2), so there are external solutions/workarounds for Premium Frequency use.
VCTCXO seem to be cheap and low power up to 48~52MHz (clipped sine), and available with higher prices and Icc jumps above 52MHz.
Above 100MHz, they tend to be LVDS/PECL etc
Attached are both P2D2 and the P2-ES versions.
The streamer is logging 20,000 8bit samples from P56-P63 at the clock frequency. I have a little routine that is outputting incrementing counts to P56-61 which is then displayed on the VGA monitor. Here is a pic with closeup insert. The smallest clocks are 2 clocks (2 pixels) wide.
I will be using this to scope my SD ROM Driver timing
Very nice. Now if only we could fit that into the ROM