PLL wobble testing using HD VGA
Tubular
Posts: 4,702
in Propeller 2
During testing these past couple of months we've noticed some 'pll wobbles' affecting HD VGA screens. The wobbles can be brought on by excessive PLL divisors and/or elevated temperature (approx low to mid 50 C's surface temperature, higher than P2-Eval board can naturally get to with its own self heating).
In this thread we'll try and get some numbers together. Also if anyone has ideas for some kind of automated detection when the wobbles occur, that would help. I can't spot it on the PLL current drawn through V2831 unfortunately, and only just on the DMM in frequency mode, and then only visually
The photo below has a shutter time around 1/30 sec which probably means it has two stacked frames. I'll try and get a shot with 1/60 sec to match the vertical refresh. The test pattern is a black and white grid, single white lines are 32 pixels apart in X direction and 20 pixels apart in Y direction.
If a pixel deviates + / - 7 pixels in the X direction, I believe that translates to + / - 50 nsec
We're also using a PLL divisor of 14 to hit 138.57 MHz (1920x1080 60fps with reduced blanking 1), things are generally better and divisors of 2 or 3
I need to do some more work on hsync to make sure there's not something else going on, however we have done testing with a pin exporting clock_freq/1000 and it does show the wobble simultaneously with the video wobble.
Pnut_v32i test code also attached
In this thread we'll try and get some numbers together. Also if anyone has ideas for some kind of automated detection when the wobbles occur, that would help. I can't spot it on the PLL current drawn through V2831 unfortunately, and only just on the DMM in frequency mode, and then only visually
The photo below has a shutter time around 1/30 sec which probably means it has two stacked frames. I'll try and get a shot with 1/60 sec to match the vertical refresh. The test pattern is a black and white grid, single white lines are 32 pixels apart in X direction and 20 pixels apart in Y direction.
If a pixel deviates + / - 7 pixels in the X direction, I believe that translates to + / - 50 nsec
We're also using a PLL divisor of 14 to hit 138.57 MHz (1920x1080 60fps with reduced blanking 1), things are generally better and divisors of 2 or 3
I need to do some more work on hsync to make sure there's not something else going on, however we have done testing with a pin exporting clock_freq/1000 and it does show the wobble simultaneously with the video wobble.
Pnut_v32i test code also attached
4608 x 3456 - 3M
spin2
28K
Comments
Yeah, while this testing was with /14 because it makes things easier to bring on & photograph. I've certainly seen similar with /3. I haven't tried /2 yet
Is that a zoomed portion of the screen ? - there seems to be some ringing effects, in the vertical axis Could that be 3 stacked frames ? I can see 3 ringing overlayed there.
The jitter I was seeing at 160MHz, using my 4046 phase detector, at /64, was less than a full XTAL cycle, but was more than 1 SysCLK
I had to go to /64 to get an amplified jitter, enough for my 100Msps scope to grab.
That image seems to span ~7 pixels, so is closer to +/- 3.5 pixels, which is similar to my /64 jitter, but you use /14 where I would see less.
Given the possible frame sync aspect here, I wonder if some of this is also showing the Monitor PLL struggling with P2 signals ?
Is the HSync present during vertical flyback ?
I wonder if the P2 gets noiser, does the monitor lose the ability to follow ?
Based on those jitter plots posted earlier, (reciprocal counter) I suggested using a Smart Pin mode, Capture SysCLKS over X-Xtal Cycles (good for Sysclks comfortably above 40MHz)
That needs just XO mapped to an adjacent Smart pin, and maybe a higher CL can compensate for the skew in loading that results ?
This will not have the nice background slope of the earlier plots, which showed the Xtal temperature, but it will catch residual averages of > 1 SysCLK.
X-Xtal cycles can be varied to find the best sensitivity - too small X will not have enough accumulated error, and too large X will average to zero.
Does anyone have a good enough spectrum analyzer to get a close-in capture of a smart pin toggling ?
Addit: If you set that X in the smart-pin mode Capture SysCLKS for X-Whole Cycles, to a line-time (~ 300 Xtal Cycles ?) you should capture the same as a single-frame image does, to 1 pixel LSB.
If that is less than the screen disturbance, you have Monitor PLL effects adding to P2 PLL effects.
First 2 are same settings, and sweeping (warming) thru some 'hot spot', then settling to a more stable zone.
That does seem to indicate a couple of preferred frequencies in play.
Second 2 show /8 and /16 PFD relative differences - higher PFD divide is worse.
I agree it'd be good to nail this better, though
Nice plots. Did you try connection to a pin giving 10MHz to avoid loading XO, for spectrum plots of Crystal only (no PLL), and Crystal with PLL running (maybe PFD /1 and PFD/64).
What are the PLL settings for the last plot ?
My scope captures and counter suggest it is not totally losing frequency lock, in the long term averages sense.
Comparing Xtal XO with a 20MHz out, from SysCLK/8, still shows an eye.
The phase-lock operation, has more wobble than would be ideal, and there are some cases where that also changes within a temperature zone. (better either side)
We could connect the crystal oscillator to an input pin. The smart pin can measure frequency. Or sample it with the streamer and do an FFT or other analysis.
Notes: I'm using pin 16 for the clock output, with its LDO selected. I use a 10x scope probe to transfer the signal from P2ES board to USRP. The moderate amplitude peak in the middle of the graph is from the USRP1, not the Propeller. I think it's a result of rounding in the digital down converter. Adding or subtracting 1/2 LSB might make it go away.
I don't have a VGA setup, but it might be fun to try VGA with RCFAST.
a time-domain phenomenon.
I wonder where that 10.113MHz comes from ? It's not half RCFAST ?
Is that -96dB correct, as the peak seems to only hit -40dB ?
I think Chip has said RCFAST cannot drive the PLL, but maybe RCFAST is near enough to drive a good portion of a 25MHz VGA scan ?.
Plot 1, dv=1, mlt=8, pdv=1, VCO freq = 160M
Plot 2, dv=1, mlt=16, pdv=2, VCO freq = 320M
Looks like the 320MHz vco is a little bit better. Shouldn't be a problem, the documentation says 100-400MHz. From what I've seen to minimize jitter, use only d
iv=1 or 2.
Plot 3, dv=4, mlt=64, pdv=2, VCO freq = 320M spurs .5M, should be 5M?
Plot 4, dv=9, mlt=144, pdv=2, VCO freq = 320M spurs 1.111M, 2.222M present as expected
Plot 5, dv=10, mlt=160, pdv=2, VCO freq = 320M spurs 2M, ok, this is expected
There is some weirdness going on with dividers 3-9.
RCFAST should be able to do VGA at about 56 Hz.
Plugging 640x480 60Hz into the Vesa CVT generator shows a dot clock of 23.75 MHz (normal), 23.5 MHz (reduced blanking v1, and about the value RCFAST generates), 21.363 MHz (reduced blanking v2).
We should totally try that and see whether the monitors object
https://www.facebook.com/terrytrapp/videos/10219225276769691/?comment_id=10219225378332230¬if_id=1547787822021783¬if_t=video_comment
Ken posted some comments. Seems Chip has this well in hand
If VGA is too fast for RCFAST, TV won't be.
How accurate is the X axis - those peaks are not quite 0.5MHz, if that is calibrated ?
There are some peaks very close to the main Fo, on plot 3 but they look to be ~ 100kHz
Can you plot /2 *32 for a midway check between these two ?
Plot 1, dv=2, mlt=32, pdv=2, VCO freq = 320M
Plot 2, dv=2, mlt=32, pdv=2, VCO freq = 320M
Plot 3, dv=4, mlt=64, pdv=2, VCO freq = 320M spur only
Plot 4, dv=5, mlt=80, pdv=2, VCO freq = 320M spur only
Good catch! It was less than 500k. The numbers shown are just the location of the cursor, I did a sloppy job positioning it and didn't notice because it wasn't in the screenshot.
The ~500kHz spur at /4 is temperature dependent. Blowing on the board made it go above 500k. It's also present at /5. If the temperature allows it to be almost exactly 500k it does seem to "lock on" and shows a cleaner spike.
Interesting results Terry.
I'm curious if you repeated the same test using Cordic Crickets.
It differs in it's video driver and doesn't generate video lines on the fly like Invaders does.
Does it show jitter like Invaders with the same div/mult values?
Still doing further tests regarding that with Tubular.
That rather suggests an unstable linear amplifier (in the PFD) could be oscillating, and Chip does change the bias/gain with the divider value chosen, so that will vary the stability points.
I had made my 4046 filter rather more low pass than 500kHz, as I was not expecting that type of issue, I'll try and move the cutoff higher, and see what is revealed.
eg the LDOs oscillate at 245kHz with a scope probe load, and no output load (the jumper connects the 4u7 CAP to the regulator, with no jumper there is no load)
They do not connect to P2 when doing this, (and P2D2 does not have them) but you never know...
sensitive to cold-spray, and wobble a bit on entering the DAC mode on loading the test. Spectrum of the tone plus
side bands, and of the spur itself in isolation appended.
OSCMODE $010C3F04 with setclk in spin2, pwm random dither (%0000_0000_000_10100_00000000_01_00010_0),
updating at 10MHz using pipelined cordic sinewave. Pin 48 used. Spin cog still running using pausems(10) which would mean 100Hz spurs if anything from that.
That scales to ~ 700kHz offsets relative to 20MHz, so is in the similar ballpark to the other test spectrum. done on a different P2 ?
its present at baseband too, it just intermodulates with any signal on the pin.
Where does that wandering 7kHz come from ? - is it on the supply rails ?
good thermal bond to the PCB means the cool-spray will have affected nearby components).
Below are the captures - there is a definite 30kHz ringing, of time-varying amplitude, (no sign of 500kHz) and the chip warming up does shift (reduce) the amplitude of the ringing.
Jmg, I think this is great news!
This means that the second-order RC filter on the VCO bias needs more resistance on the second resistor. I was suspecting something like this was happening. Simulations should confirm this.