Shop OBEX P1 Docs P2 Docs Learn Events
VGA 1920x1080x4bpp @148.5MHz - Rock Stable and 240 chars x 135 lines :) - Page 5 — Parallax Forums

VGA 1920x1080x4bpp @148.5MHz - Rock Stable and 240 chars x 135 lines :)

1235

Comments

  • RaymanRayman Posts: 13,800
    Ok, I see now that letters on white background is going to be the hardest to make look perfect.

    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.).
  • RaymanRayman Posts: 13,800
    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
    3024 x 4032 - 1M
  • RaymanRayman Posts: 13,800
    edited 2018-12-27 17:31
    The other issue is ghosting...
    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...
    3024 x 4032 - 7M
  • cgraceycgracey Posts: 14,133
    edited 2018-12-27 18:20
    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.
  • RaymanRayman Posts: 13,800
    I think that's what cluso/ozpropdev have:
    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
    
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    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
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    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 ?
    Rayman wrote: »
    Maybe we need termination resistors?
    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.

  • RaymanRayman Posts: 13,800
    cable is ~1.5 meters...
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    cable is ~1.5 meters...

    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.
  • That could be simple impedance mismatch
  • cgraceycgracey Posts: 14,133
    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.
  • RaymanRayman Posts: 13,800
    I tried 10 and 22 ohms series resistors... Doesn't help...
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    I tried 10 and 22 ohms series resistors... Doesn't help...

    Does it get steadily worse ?


  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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%
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    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.
  • RaymanRayman Posts: 13,800
    jmg wrote: »
    Does it get steadily worse ?

    Don't see any difference, other than gets hair darker...

    Hopefully, just my cabling...

  • jmgjmg Posts: 15,140
    Rayman wrote: »
    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 ...
    > N=N+1;(1-148.5/((20/N)*round(148.5/(20/N))))*100
    DIV   %148.5MHz    PFD/LineScan
    /1  = -6.0714      314.29
    /2  = 1            146.67
    /3  = -1.25        100
    /4  = 1            73.333
    /5  = -0.33784     59.459
    /6  = 1            48.889
    /7  = 0.048077     42.308
    /8  = -0.67797     37.288
    /9  = 0.26119      32.836
    /10 = -0.33784     29.73
    /11 = 0.39634      26.829
    /12 = -0.11236     24.719
    /13 = 0.48969      22.68
    /14 = 0.048077     21.154
    /15 = -0.33784     19.82
    /16 = 0.16807      18.487
    /17 = -0.17857     17.46
    /18 = 0.26119      16.418
    /19 = -0.053191    15.603
    /20 = 0.33557      14.765
    /21 = 0.048077     14.103
    /22 = -0.21472     13.497
    /23 = 0.13158      12.865
    /24 = -0.11236     12.36
    /25 = 0.20161      11.828
    /26 = -0.025907    11.399
    /27 = -0.2375      11
    /28 = 0.048077     10.577
    /29 = -0.15116     10.233
    /30 = 0.11211      9.8655
    /31 = -0.076087    9.5652
    /32 = 0.16807      9.2437
    /33 = -0.010204    8.9796
    /34 = -0.17857     8.7302
    /35 = 0.048077     8.4615
    /36 = -0.11236     8.2397
    /37 = 0.1          8
    /38 = -0.053191    7.8014
    /39 = 0.14655      7.5862
    /40 = 0            7.4074
    /41 = -0.1398      7.2368
    /42 = 0.048077     7.0513
    /43 = -0.086207    6.8966
    /44 = 0.091743     6.7278
    /45 = -0.037425    6.5868
    /46 = 0.13158      6.4327
    /47 = 0.0071633    6.3037
    /48 = -0.11236     6.1798
    /49 = 0.048077     6.044
    /50 = -0.067385    5.9299
    /51 = 0.085752     5.8047
    /52 = -0.025907    5.6995
    /53 = 0.12056      5.5838
    /54 = 0.012469     5.4863
    /55 = -0.091912    5.3922
    /56 = 0.048077     5.2885
    /57 = -0.053191    5.2009
    /58 = 0.081206     5.1044
    /59 = -0.017123    5.0228
    /60 = -0.11236     4.9438
    /61 = 0.016556     4.8565
    /62 = -0.076087    4.7826
    /63 = 0.048077     4.7009
    /64 = -0.042105    4.6316
    
    PFD/LineScan = (20/N)/(((20/N)*round(148.5/(20/N)))/2200)
    
    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,
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    ..
    I'm seeing some wavering in the white level in horizontal bands ...
    Rayman wrote: »
    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 ?
  • Cluso99Cluso99 Posts: 18,066
    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.
  • cgraceycgracey Posts: 14,133
    edited 2018-12-28 01:21
    We will get this 0.5MHz PFD problem fixed in the next silicon. Simulations should reveal whatever the problem is.
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    We will get this 0.5MHz PFD problem fixed in the next silicon. Simulations should reveal whatever the problem is.
    That would be fantastic, although of course we can live with it.
    The divisions and multipliers give us lots of combinations.
  • RaymanRayman Posts: 13,800
    Rayman wrote: »
    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

    Ok, changing the V0007 power jumper from VIO to 3V3 does fix this banding issue.
  • jmg wrote: »
    Rayman wrote: »
    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
     XDIV=40; XMUL=297; ppm=(1-148.5M/(XMUL*20M/XDIV))/1u  ppm = 0 - but 0.5MHz PFD  << tested, jitters
    
     XDIV=33; XMUL=245; ppm = -102.0408  XDIVP = 1
     XDIV=26; XMUL=193; ppm = -259.0673  XDIVP = 1
     XDIV=7;  XMUL=52;  ppm = 480.76923  XDIVP = 1  PFD = 2.857M
     
     XDIV=20; XMUL=193; ppm = 0          XDIVP = 2  PFD = 1M
     XDIV=13; XMUL=193; ppm = -259.0673  XDIVP = 2  PFD = 1.538M
    
     XDIV=10;XMUL=74;   ppm = -3378  (148MHz, PFD 2MHz )  ??
     XDIV=15, XMUL=111  ppm = -3378  (148MHz, PFD 1.333' MHz ) << tested, reports OK
    

    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.


    640 x 563 - 647K
    640 x 554 - 644K
    640 x 550 - 596K
    640 x 556 - 642K
  • jmgjmg Posts: 15,140
    ...
    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.



  • jmg wrote: »
    ...
    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.
  • jmgjmg Posts: 15,140
    edited 2018-12-31 23:39
    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
    Device SpeedGrade Xtal     Output(MHz)  MinFvco(GHz)    MaxFvco(GHz)   Icc         Jitter
     Si549.A         152.6    0.2~1500     10.8            12.511886114    87mA CMOS   95fs RMS
     Si549.B         152.6    0.2~800      10.8            12.206718160    87mA CMOS   95fs RMS
     Si549.C         152.6    0.2~325      10.8            12.206718160    87mA CMOS   95fs RMS
     Si5351A         25~27    0.002~200    0.6             0.9             22mA CMOS   50~70ps pk-pk
    
    

    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
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-01-30 13:21
    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 :)

    LA_VGA_012_01ES.jpg

  • Cluso99 wrote: »
    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 :)

    LA_VGA_012_01ES.jpg

    Very nice. Now if only we could fit that into the ROM :)
  • Cluso99Cluso99 Posts: 18,066
    Cluso99 wrote: »
    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 :)

    LA_VGA_012_01ES.jpg

    Very nice. Now if only we could fit that into the ROM :)
    Actually it’s not that large. Without buffers, maybe 1KB ???
  • cgraceycgracey Posts: 14,133
    Very nice, Ray! What PLL values are you using?
Sign In or Register to comment.