VGA jitter thermal issue?
Rayman
Posts: 14,646
in Propeller 2
I thought I had a handle on VGA jitter by just keeping crystal XDIV at 10...
Chip's VGA demo seems perfectly fine at 250 MHz on P2 EV board.
But, seeing something different with my 90's 3D demo... It starts out fine.
But, after ~10 minutes the video starts jittering. Slowly that jittering becomes shaking.
It appears to me to be a thermal issue. If I drop the clock to 100 MHz, it stops...
It must be that the 90's 3D demo gets hotter due to more cogs being used...
Chip's VGA demo seems perfectly fine at 250 MHz on P2 EV board.
But, seeing something different with my 90's 3D demo... It starts out fine.
But, after ~10 minutes the video starts jittering. Slowly that jittering becomes shaking.
It appears to me to be a thermal issue. If I drop the clock to 100 MHz, it stops...
It must be that the 90's 3D demo gets hotter due to more cogs being used...
Comments
I do, but not until the weekend.
Did you try a higher PFD, of /2 then *25, to get the 250MHz ?
Do you have a 50MHz xtal handy ? - be interesting to also test /1 then *5 for jitter, as well as check if Xtal OSC & PFD works at 50MHz
Jitter is certainly thermally affected, as the temperature sweeps the operating point of the VCO.
As the chip warms, the VCO VDD needs to slowly increase to keep the locked-MHz constant.
I think that voltage change, also changes the parasitic capacitances, and combined with the parasitic L's, that sweeps the ringing frequencies around the VCO.
The net result is the VCO transfer is not as linear/smooth as ideal, and some 'snap to' and 'snap away' points exist.
You could also try a slight change in the target MHz, or a change in the sysclks per line ?
The Xtal does vary too, tho not by much, mine starts ~ -7ppm and goes below -20ppm as it warms up.
Yes, though it was actually at 53 C (more recently), but it was quite reproduceable. I was using a 1000w halogen worklight to gently heat the surface of the chip to go above, then below the temperature at which the jitter shakes the screen
The good news is that once you're 'through' (increasing temperature), things settle down back to normal.
However, I've been trying to get a handle on how to automatically measure and perhaps obviate this. What I do know so far is
- its very reproducable at temperature sweet spots
- can measure it using the Keysight meter in frequency mode, just, watching a pin with /1000 dot clock output
- its seems better (and higher onset temps) with lower PLL divisors eg 3
- it seems relatively bad with divisors around 13~15 (does this correspond with Saucy's PLL spectrums?)
- some monitors seem to fight it better than others (Dell 2405fpw better)
- need a contrived test pattern with vertical stripes so we can measure short term + and -
- make sure its not jitter/distortion of the HSYNC pulse, which looks pretty ugly from cable loading
- consider driving HSYNC using standard TTL (19 ohm) rather than 75 ohm, and/or terminating 75 ohm R
- consider PLL decoupling caps, measure PLL current etc
- use CVT reduced blanking timing standards to reduce dot clock rates by 20/24%, in turn limiting self heating
- eg 1920x1080 reduces from 182.5 MHz to 148.5 MHz (v1, -20%) or even 138 MHz (v2, -24%)
- when slowly running through an episode, there are a couple of sharp 'warning shots' where the screen shimmers just briefly, before the 'main event' where everything shimmers for a relatively long time compared to the 'warning shots'. When reversing the temperature, these events play out in reverse.
The other interesting observation when running very slowly through the 'main event' episode, is that the graphics demo has two phases - the 'wipe phase' where lines, text etc are changing/being populated, and the 'steady state phase'. Both phases are something like 2 seconds, typically. Whats interesting is that
- initially, the shimmer will only be seen on the wipe phase,
- then later it will be on seen during both wipe and steady phases
- then finally it will only be during steady phase
- (I might have the above back to front)
I'll post some screencaps etc soon
As you can see from the vertical axis and stats, the multimeter is very much zoomed in and only just resolves whats going on
This is from using HD VGA (1920x1080 60p) and v2 of reduced blanking (2013 vintage), hence the dot clock of 138 MHz (/1000 and shown as 138 kHz on the meter)
In earlier tests on EFM8 MCUs seeing if the inbuilt RC oscillators were good enough for PAL level video, I noticed the pixel-sampling effect magnified jitter.
On a high resolution monitor, it was tolerable from a distance, but on the lower pixel displays, the jump of one pixel is of course larger, and where the jitter did cross a pixel boundary, it was visibly worse.
Not all pixels had this effect, as for some the sampling was still fine (centred)
Self-measuring on a P2 is going to be tricky, because the effect is (small) phase modulation, not frequency shift.
I think you could couple XO to another pin (shame that is not available internally..), and use a N-Cycles Time interval smart pin mode, but that requires jitter above sysclks.
In my tests using a HC4046 phase comparison, and scope, the phase jitter is usually under half a Xtal-cycle. Significant, but not so easy to self-measure.
I'm not sure on the threshold modes, but I think you could vary the threshold on that coupled pin, and thus walk the xtal phase thru +/- 45' or so, and that will cross a faster Sysclk edge.
There was one topic on comparator/threshold mode here (no mention of MHz abilities - needs to be ok at 20MHz for this to work ?)
A histogram sweep could expose the jitter to fractions of a SysCLK, but all this is getting into quite complex SW.
A nominal 3V sine at 20MHz is ~5.3052ns/V slew, or 0.94248V in 5ns & ~+/- 5ns seems practical.
That's appx 73.113 DAC steps (assumes 8b threshold DAC) to cover 5ns, or 14.623 steps per ns, or 68.387 ps/DAC step
With extra pin connect adding C, those might nudge down to close to 100ps/DAC Step
It may be that 30pF select tolerates XO cap loading more than 15pF, easy enough to try.
Nice plots. What is that number measuring exactly, is that heating, or cooling phase ?
I had been assuming the observed Xtal changes were too small to be any issue (10~15ppm), but what you plot there, is varying and trending by sub ppm levels.
1-138588.10/138588.20 = 0.721ppm - that may well be the Xtal sweeping in frequency.
One test would be to use an external oscillator, that is not thermally coupled to P2
Dell 2405FPW goes to 1920x1200 60p and i've had P2 successfully driving at that resolution. Rogloh has the same monitor
Thats interesting. It seems like many pixels are affected, but perhaps some closer inspection might reveal something.
Some good ideas. Certainly we can try changing the loading caps and see if that moves things.
Next, I am going to look at the PLL current through pin V2831, and see if it increases where things go wobbly. If it does, monitoring that voltage/current might be an option
After observing some of this with you yesterday Tubular, I sort of wonder if this is some small amount of frame sync jitter visually interacting with the data you are updating on the screen making it more visible during updates vs static image (and maybe somehow beating/strobing with the demo redraw period)....? Because the hsync signal quality was really bad too in that setup, I'd suspect the same will be happening to vsync. Be good to test it with a hires analog monitor as well. It may also be worth whipping up a quick VGA connector breakout board for better/further testing before Parallax VGA is available, unless that will be coming very soon. Your ribbon cable section was short but probably not ideal at the higher pixel rates being used.
Update: just read another thread and seems the Parallax breakouts should be coming fairly soon. Hopefully the VGA one will be suitable for better testing of this issue.
FYI, here is the pull range of the CAP changes, xtal only, no > 100MHz heating (those numbers move ~ -15ppm as Xtal warms from faster P2
I'm not sure how safe it is to change cap settings on the fly, be interesting to see if it is tolerated ?
How do I relate the 138588.20 numbers back to the PLL/VCO ?
This is close to 138.187 MHz dot clock used for "CVT reduced blanking v2" for 1920x1080 60p 133.187 (rb v2)
Roger, yes we should definitely try your analog monitor. I'll post those hsync signal pics later
1-138588.20*1000/((20M/3)*20) = 3.9411%
Is that plot when cooling, or when warming ? My Xtal has a negative ppm, so drops Hz as it heats. I presume all P2-EV boards are quite similar.
I just tried dialling up 20/3*20/1 (133.333 theoretical) and it shows 133.351 on the meter
its possible also our /1000 frequency divider code is 'out', I'll ask OzPropDev to check it later as he has an accurate freq meter,
Trying it now. This seems to work much better... No sign of jitter...
20 / 14 * 97 / 1, gives a theoretical 138.571 MHz
while aiming for 138.500 (Vesa CVT spec, v1 rather than v2 reduced blanking, 1920x1080 60p)
When I dial up these PLL settings just now, the meter shows 138.589 MHz (so same as those prev recordings). The meter is Keysight 34465a, gate time 100 msec
When testing I tend to oscillate between /3 (PLL wobbles are fewer / farther between) and /13~/15 (brings them on quicker) .
Do you have any HC4060 chips - connecting one to the Xtal XO, and running a similar pass could check the Xtal Osc is actually ok.
A tap of 2^7 is similar ballpark 20M/2^7 = 156250Hz,
%CC = 01, no loading caps, meter reads 138.589 MHz <-- what i've been using for all VGA testing before now
%CC = 10, 15pf loading caps, meter reads 138.569 (closer to 138.571 theoretical, 20/14*97)
%CC = 11, 30pF loading caps, meter reads 138.563
I was still able to observe a wobble with 15pF loading caps
I wouldn't have an HC4060, sorry. Maybe at old cmos (non 74hc) 4060. However we also observed wobbles on P2D2, which has a 12 MHz TCXO, so don't think its xtal related (alone)
Somehow, having XDIV=10 must have made clock marginal...
Seems happy with XDIV=2
A higher PFD makes the PLL control 'stiffer', and it is more able to 'strong arm' the VCO to where it wants.
At some point, the jitter will drop below what the monitor can display - ie once the eye of each pixel is clean enough, the jitter will clean up.
I think that is why modest changes can make things much better, you drop inside the sampling windows.
Thanks, that's consistent with my & other measurements.
The 15pF loading seemed to have tighter wobble amplitude, perhaps.
I'll play a bit further using /14 and take some more caps, before heading back to /3
I'm impressed but a tad puzzled that it is able to show this, as the PLL should average to the Xtal frequency, over long gate times.
Maybe it does average, but not all the way to zero, and maybe the residual phase error, is large enough to capture.
If you vary the gate time to 1s or 10ms, how does that affect the ability to show this zone ?
There may be a gate time sweet spot, that best shows this ?
Data says Keysight 34465a uses a reciprocal counter, but is a tad vague on the SysCLK ( I found an older Keysight 3458A, that does define 10MHz, quite common)
Those 100ms numbers you listed above, indicate a remarkable LSB
1-138588.07/138588.06 = -7.215e-8
A generic 10MHz reciprocal counter with 100ms gate, gives this LSB step
13859/(1e6-1)*1e7 = 138590.138
or change to 100MHz timebase gives LSB more in line with your readings.
13859/(1e7-1)*1e8 = 138590.0138
Maybe Keysight now use the better 100MHz chip, because that is all they have ?
Working back from all this, maybe the Smart Pin Time interval mode can be good enough to show this too ?
eg if you set to 100ms on XO-linked pin, that's 2M XO counts, and that should capture SysCLK count of 13857143, which is the same sub 0.1ppm LSB your meter gives.
Looks like it can do this almost in the background ?
%10011 = For X periods, count time
X[31:0] establishes how many A-input rise/edge to B-input rise/edge periods are to be measured.
The X here can be pretty much any value, whatever has highest sensitivity
Measure might be possible with a XO to Pin (maybe with a modest Series R, to try to isolate the added C effect).
Obviate is a bit more of a challenge, as it seems to be a VCO operating curve transfer behaviour.
ie X millivolts at Y degrees gives the target MHz, but at some values of Y that also coincides with a bump/wrinkle in the curve.
Higher VCO's seem better (less wrinkles there?), so you could also try 20/7*97/2
Maybe switch of 20/7*97/2 <-> 20/14*97/1 during frame flyback, is possible to go unnoticed ?
Because the Monitor pixel sampling has to be based on the H Sync edges, finer movement of the hsync could well improve the eye placement.
At very high pixel clocks there is little SW scope to vary this, but at lower VGA resolutions, (640x480) & 25~40MHz dot clocks, there is room for some software fine adjust of the H-edge to Pixel-Edge phase offsets.
ie if you hit one, and change the Xtal CL, is that change enough to step over into a clean area ?
A ceramic resonator would offer larger dF with CL, (eg CSTNE20M0VH3L000R0) they do not come in the supported xtal package, but could be test-wired.
If that is not enough, someone mentioned ozpropdev has a Si5351A library for Prop ?
Adafruit have a low cost Si5351A PCB, and there is a nice TCXO variant here, for $16