Shop Learn
VGA jitter thermal issue? — Parallax Forums

VGA jitter thermal issue?

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...

Comments

  • cgraceycgracey Posts: 13,627
    Tubular noticed some increased noise right around 45C.
  • Make a quick thermocouple, if you don't have a way to measure temp.

    I do, but not until the weekend.
  • jmgjmg Posts: 14,820
    Rayman wrote: »
    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...

    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.
  • TubularTubular Posts: 4,414
    edited 2019-01-03 20:05
    cgracey wrote: »
    Tubular noticed some increased noise right around 45C.

    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
  • Here's the multimeter screen shot showing a shimmer event, the brief warning shots followed by the 'main event'.

    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)

    SCREEN_2.png
    480 x 289 - 7K
  • jmgjmg Posts: 14,820
    Tubular wrote: »
    - some monitors seem to fight it better than others (Dell 2405fpw better)
    Is that a higher resolution monitor ?
    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)
    Tubular wrote: »
    However, I've been trying to get a handle on how to automatically measure and perhaps obviate this.

    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.
  • Here's the raw data from the multimeter. Of the 1729 samples, 1300 to 1600 covers the event shown in the above screen cap

    pll_wobble_dataset2_graphs.png
  • jmgjmg Posts: 14,820
    Tubular wrote: »
    Here's the raw data from the multimeter. Of the 1729 samples, 1300 to 1600 covers the event shown in the above screen cap

    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



  • RaymanRayman Posts: 12,254
    So there's a certain temperature range where there is jitter and gets steady again at higher temperature? Strange...
  • jmg wrote: »
    Is that a higher resolution monitor ?

    Dell 2405FPW goes to 1920x1200 60p and i've had P2 successfully driving at that resolution. Rogloh has the same monitor
    jmg wrote: »
    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)

    Thats interesting. It seems like many pixels are affected, but perhaps some closer inspection might reveal something.
    Tubular wrote: »
    However, I've been trying to get a handle on how to automatically measure and perhaps obviate this.
    jmg wrote: »
    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.

    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
  • roglohrogloh Posts: 3,637
    edited 2019-01-03 21:43
    Tubular wrote: »
    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

    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.
  • roglohrogloh Posts: 3,637
    edited 2019-01-03 21:51
    Deleted duplicate
  • jmgjmg Posts: 14,820
    Tubular wrote: »
    Certainly we can try changing the loading caps and see if that moves things.

    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
    %CC     XI status   XO status       XI/XO Z   XI/XO caps        Measures      ppm change  PLL                                   
    %00     ignored     float           Hi-Z      OFF
    %01     input       600-ohm drive   1M-ohm    OFF            -> 1000.1439Hz   +144   ppm      
    %10     input       600-ohm drive   1M-ohm    15pF per pin   ->  999.9933Hz   -6.700 ppm  
    %11     input       600-ohm drive   1M-ohm    30pF per pin   ->  999.9472Hz   -53 ppm       
    

    I'm not sure how safe it is to change cap settings on the fly, be interesting to see if it is tolerated ?

    Tubular wrote: »
    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

    How do I relate the 138588.20 numbers back to the PLL/VCO ?



  • TubularTubular Posts: 4,414
    edited 2019-01-03 23:05
    The PLL is running 20 / 3 * 20 / 1 = 133.33 MHz. see below

    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
  • jmgjmg Posts: 14,820
    edited 2019-01-03 22:29
    Tubular wrote: »
    The PLL is running 20 / 3 * 20 / 1 = 133.33 MHz.

    This is close to 138.187 MHz dot clock used for "CVT reduced blanking v2" for 1920x1080 60p
    Thanks, but there seems some offset here of ~ 4% - is that the meter calibration ?
    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.


  • jmg I was probably messing with something at the time, sorry

    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,
    test_clock	rep	#2,#0
    		drvnot	#14
    		waitx	#496
    


  • jmgjmg Posts: 14,820
    Tubular wrote: »
    Here's the multimeter screen shot showing a shimmer event, the brief warning shots followed by the 'main event'.
    What is the (fancy) multimeter model number and reading rate used here ?


  • RaymanRayman Posts: 12,254
    jmg wrote: »

    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 ...

    Trying it now. This seems to work much better... No sign of jitter...

  • Jmg re 138.58 MHz, looks like I was using the following at the time
    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) .
  • jmgjmg Posts: 14,820
    Was that underlying positive slope on a heating, or cooling pass ?
    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,
  • Changing the loading caps,

    %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)
  • Also, my P2Eval freq drops when heated, so it would have been a cooling slope in the data above.
  • RaymanRayman Posts: 12,254
    I don't think my board is anywhere near 45 degrees at 250 MHz and a few cogs running.

    Somehow, having XDIV=10 must have made clock marginal...

    Seems happy with XDIV=2
  • jmgjmg Posts: 14,820
    Rayman wrote: »
    I don't think my board is anywhere near 45 degrees at 250 MHz and a few cogs running.

    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.
    Tubular wrote: »
    Also, my P2Eval freq drops when heated, so it would have been a cooling slope in the data above.
    Thanks, that's consistent with my & other measurements.
  • I've played a bit further with the 30pF loading, jmg. It seems to have wilder and longer wobble swings, at first glance, although its hard to be completely objective about it.

    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

  • jmgjmg Posts: 14,820
    edited 2019-01-04 00:58
    Tubular wrote: »
    ... The meter is Keysight 34465a, gate time 100 msec

    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
    Tubular wrote: »
    However, I've been trying to get a handle on how to automatically measure and perhaps obviate this...
    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 ?

  • Tubular wrote: »
    I've played a bit further with the 30pF loading, jmg. It seems to have wilder and longer wobble swings, at first glance, although its hard to be completely objective about it.

    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
    Speaking of capacitors, I do recall I added a capacitor across the hsync output for my P1 protoboard to reduce the line jitter on higher resolutions. It seemed to help and may also somewhat clean up that ugly sync signal you had Lachlan. Just got that board out and it looks like I'd used 100pF from pin 17 (HSYNC) to ground. Might be worth a try to see if it removes any of your screen problems.

    cap.jpg
    794 x 601 - 126K
    cap.jpg 125.7K
  • jmgjmg Posts: 14,820
    rogloh wrote: »
    Speaking of capacitors, I do recall I added a capacitor across the hsync output for my P1 protoboard to reduce the line jitter on higher resolutions. It seemed to help and may also somewhat clean up that ugly sync signal you had Lachlan. Just got that board out and it looks like I'd used 100pF from pin 17 (HSYNC) to ground. Might be worth a try to see if it removes any of your screen problems.

    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.

  • jmgjmg Posts: 14,820
    Tubular wrote: »
    Changing the loading caps,

    %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
    The Xtal does not offer large ppm shifts, I wonder what the width of those 'bad zones' are in ppm ?
    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
Sign In or Register to comment.