Shop OBEX P1 Docs P2 Docs Learn Events
Testing new P2 EVAL RevB board with glob-top chip - Page 2 — Parallax Forums

Testing new P2 EVAL RevB board with glob-top chip

24

Comments

  • Good work Eric, thanks.
    btw, I'm still using your old loadp2.
    loadp2 - a loader for the propeller 2 - version 0.005, 2018-04-04
    

    I wish I could take credit for loadp2, but it's @"Dave Hein" 's work -- I'm just doing some minor updates to it :).

    Here's a binary of the new loadp2 which should allow for fast loading on the new chips.
  • rogloh wrote: »
    @ersmith , I have some changes to enable higher baud rates like 2000000 on Macs using your latest loadp2 codebase I grabbed today. I fixed your Makefile to enable it to also build Mac specific code and put in the higher baud rate changes to the osint_linux.c file. This Makefile.txt is just renamed from Makefile to let me post it here.
    Thanks, Roger! Those changes look good and I've put them up in my repo.

    Eric
  • Cluso99Cluso99 Posts: 18,066
    rogloh wrote: »
    Was able to download and run my prior p2gcc based Micropython binary and run Chip's earlier HDMI demo on this rev B EVAL board. The colourful 16bpp bird image presented looks very nice (albeit upside down) on my old Dell 2405FPW which syncs fine to the 640x350 image it is being sent. Don't notice any shimmer or pixel sparkles etc with the magnifying glass. Sending over a 1.8m HDMI to DVI cable with the Digital Video Out breakout board. The rev B P2 chip is barely even warm at 250MHz.

    This type of Dell LCD monitor is really great as it seems to sync to all sorts of things you throw at it. In the past I recall it even working down to displaying just a handful of active scanlines which it scales up to the full screen.

    I do hope that the USB code works out fine operating at 250MHz because having HDMI and USB together is going to be really compelling now and I don't think overclocking it to 250MHz is going to be a drama for many people given the headroom being reported. There's no USB 12 MHz oscillator frequency multiple requirement is there?

    It's a few years since I played with USB on P1. Back then I decided that 96MHz worked much better than at non 12MHz multiples so I downgraded my overclocked boards from 104MHz to 96MHz. Maybe I should have gone to 108MHz?? And then I never completed the project :(
  • jmgjmg Posts: 15,140
    edited 2019-09-18 12:46
    rogloh wrote: »
    ... There's no USB 12 MHz oscillator frequency multiple requirement is there?
    FWIR the USB development was done at 80MHz, and I’m not sure if a min MHz was determined on P2 silicon ?
    - Someone chasing min power might be interested in lowest MHz ?
    MCUs mostly use 48MHz for their USB clocks, but P2 may have SW paths that dictate min MHz ?
    It is unlikely 150~250MHz SysCLKs care at all about the MHz, but some care is likely needed to get the NCO at ~12.000MHz averaged.
  • With this rev B EVAL board I was just able to get my Dell LCD to sync fine to DVI/HDMI operating at 252MHz which is an exact multiple of 12MHz and may help with USB clocking frequencies if 250MHz is not ideal (am still hoping 250MHz is going to work fine with USB, @garryj may know more there). This rate is going outside the normal timing spec of sending VGA over HDMI slightly and some other display devices may be less forgiving of this, but I'm still happy this frequency apparently works on my own setup.
  • evanhevanh Posts: 15,126
    The monitor/TV will be fine with that. If you want to correct the syncs then increase the horizontal blanking slightly to compensate.

    Also, with the cooler running revB chip there is now some clock rate headroom to go for a 16:9 aspect screen mode.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-09-18 13:41
    ozpropdev wrote: »
    The descriptions are different and I haven't familiarised myself with them .properly. The VGA code uses 7f00_0000 and çf00_0000 and I quickly changed them to 7f08 etc. But it's still not quite right. Mind you, I didn't have much time to read it through so a quick hint should help me on my way.
    I found for VGA I had to change the CF00_0000) values to 7F01_0000.
    It all started behaving itself after that. :)

    Changing my $7F00_0000 to $7F08_0000 and my $CF00_0000 to $7F01_0000 got it working. Now I can watch video again and view BMPs and plot my Mandelbrots!

    Here's my basic parameter table. I still need to update the bit field comments.
    ' 01 '
    _hpixels	long	640
    _vlines		long 	480
    ' 03 			FP,SY,BP,DIV
    v_bs		byte	16,96,48,1	'5,5,20,2
    ' 04 '
    _fpix		long	fpixn			' pixel frequency'
    _fset		long	round(fset)		' pixel nco value'
    _palette	long 	bmporg+$100		' address of palette (normally $FC00)'
    _screen		long	bmporg+$500		' address of screen (normally $10000)'
    ' 08  		 $7F01 = output X3, X2, X1, X0 on all four DAC channels'
    m_bs		long	$7F010000+55		'before sync  <long> 32-bit immediate
    m_sn		long	$7F010000+20		'sync
    m_bv		long	$7F010000+110		'before visible
    ' 11 '
    bpp		long	8
    '*1 note: The pixel parameter is calculated and added during init'
    ' 12			'%0111_0001_eppp_xxxx   <long>    32-bit immediate              $xxxxxxxx
    m_vi		long	$7F01_0000		' *1
    ' 13 			%0111_1000_eppp_bbbb        -    8-bit RFLONG LUT              $xxxxxxxx
    m_rf		long	$7F08_0000		' *1
    ' 14 '
    _hbytes		long	640
    dacmode_s       long    %0000_0000_000_1011000000000_01_00000_0+vgacog<<8         'hsync is 123-ohm, 3.3V
    dacmode_c       long    %0000_0000_000_1011100000000_01_00000_0+vgacog<<8         'R/G/B are 75-ohm, 2.0V
    
    
  • rogloh wrote: »
    With this rev B EVAL board I was just able to get my Dell LCD to sync fine to DVI/HDMI operating at 252MHz which is an exact multiple of 12MHz and may help with USB clocking frequencies if 250MHz is not ideal (am still hoping 250MHz is going to work fine with USB, @garryj may know more there). This rate is going outside the normal timing spec of sending VGA over HDMI slightly and some other display devices may be less forgiving of this, but I'm still happy this frequency apparently works on my own setup.

    Some quick/dirty testing shows that at 250MHz USB works OK at both full-speed and low-speed (revA EVAL silicon). In my testing with VGA related sysclocks, only 148.5MHz (so far) has triggered USB frame jitter.
  • rogloh wrote: »
    With this rev B EVAL board I was just able to get my Dell LCD to sync fine to DVI/HDMI operating at 252MHz which is an exact multiple of 12MHz and may help with USB clocking frequencies if 250MHz is not ideal (am still hoping 250MHz is going to work fine with USB, @garryj may know more there). This rate is going outside the normal timing spec of sending VGA over HDMI slightly and some other display devices may be less forgiving of this, but I'm still happy this frequency apparently works on my own setup.

    252 MHz is much closer than 250 MHz to the HDMI 640x480 spec of 251.75 MHz.
  • 252MHz works too.
  • roglohrogloh Posts: 5,122
    edited 2019-09-18 23:58
    Some quick/dirty testing shows that at 250MHz USB works OK at both full-speed and low-speed (revA EVAL silicon). In my testing with VGA related sysclocks, only 148.5MHz (so far) has triggered USB frame jitter.

    Glad to hear that both 252MHz and 250MHz should work ok with USB. It's a slight pity that 148.5MHz has issues as that is probably a nice frequency of choice for HDTVs. I wonder if the rev B silicon will help in any way with its PLL changes or if 148.5MHz is just inherently a bad system clock value for getting USB working nicely. Did this frame jitter you observed cause actual USB data transfer errors/retransmissions etc or is it still able to recover all the data in the presence of the jitter?
  • garryjgarryj Posts: 337
    edited 2019-09-19 18:10
    At 148.5MHz my USB analyzer starts showing frame timing jitter (full-speed). The USB spec for a full-speed frame interval is 1.000ms +/- 500ns, and at 148.5MHz there are frames transmitted that are outside of that range. The deviation I'm seeing is in the ~500us to 604us ~500ns to 604ns range. The devices I test with still work, so they likely are a bit loose with the spec. 148MHz and 149MHz stay within range, so maybe the 500KHz XDIV value is a bit of a stretch? My knowledge of NCO workings is almost nil.
  • cgraceycgracey Posts: 14,133
    edited 2019-09-19 07:04
    garryj wrote: »
    At 148.5MHz my USB analyzer starts showing frame timing jitter (full-speed). The USB spec for a full-speed frame interval is 1.000ms +/- 500ns, and at 148.5MHz there are frames transmitted that are outside of that range. The deviation I'm seeing is in the ~500us to 604us range. The devices I test with still work, so they likely are a bit loose with the spec. 148MHz and 149MHz stay within range, so maybe the 500KHz XDIV value is a bit of a stretch? My knowledge of NCO workings is almost nil.

    Are you saying the protocol requires a 1.000ms frame interval, but your generating a 500us to 604us interval? Or, did you mean you are generating 500ns to 604ns of jitter?

    You could toggle between two different adjacent baud rates to dither the baud, making timing more accurate.
  • TonyB_ wrote: »
    252 MHz is much closer than 250 MHz to the HDMI 640x480 spec of 251.75 MHz.
    With respect to regular VGA (not sent over HDMI), an even 25MHz dot clock makes me a bit nervous because I don't know if it's guaranteed to work. I came across this just now:
    With analogue VGA monitors you can usually get away with using a 25 MHz pixel clock. However, based on the VESA tolerance of 0.5%, 25 MHz is not acceptable and displays may reject it. Note that 25.2 MHz is considered acceptable by VESA, which gives a 60 Hz refresh rate (rather than 59.940 Hz).
    So 252 MHz divided down by 10 is closer to 25.175 MHz, and perhaps it has less jitter.
  • jmgjmg Posts: 15,140
    edited 2019-09-19 13:24
    garryj wrote: »
    At 148.5MHz my USB analyzer starts showing frame timing jitter (full-speed). The USB spec for a full-speed frame interval is 1.000ms +/- 500ns, and at 148.5MHz there are frames transmitted that are outside of that range. The deviation I'm seeing is in the ~500us to 604us range. The devices I test with still work, so they likely are a bit loose with the spec. 148MHz and 149MHz stay within range, so maybe the 500KHz XDIV value is a bit of a stretch? My knowledge of NCO workings is almost nil.
    I think you mean 500~604ns of jitter ?
    148.5 is /12.375 to 12MHz or /(12+3/8) suggests 3 fractional nco bits are enough ?
    500ns deviation is quite a few sysclks at 148.5Mhz
    What is the USB NCO available step size ? Can 1 either side give a better average ?

  • cgracy wrote:
    Are you saying the protocol requires a 1.000ms frame interval, but your generating a 500us to 604us interval? Or, did you mean you are generating 500ns to 604ns of jitter?

    You could toggle between two different adjacent baud rates to dither the baud, making timing more accurate.

    Doh! Yes, 500ns to 604ns of jitter. The 1.000ms frame interval is controlled by a timer that triggers a frame transmission interrupt routine. I've tested with a dozen or so different sysclocks, and 148.5MHz (so far) has been the only outlier that generates this issue. I'll do some tweaking on both the frame timer and the USB NCO step size to see what happens.
  • evanhevanh Posts: 15,126
    I've just started trying to observe the sysclock jitter on the revA chip and compare with the revB. After some different approaches and trying different ways of using the scope I've settled on using the scope's "Repetitive" sampling mode. I think this mode is probably intended just for observing clock jitter.

    Just now I've targetted the 148.5 MHz zone and in doing so discovered that the revA chip has moods! It can jump from stable to unstable and back again without warning. Also, lower PLL frequencies are noisier in general.

    The revB chip is solid above 80 MHz on the PLL (pre-XDIVP), it progressively gets jittery lower down so we definitely need to exercise XDIVP from now on.

    Nothing notable observed with 148.5 MHz on either chip.

  • evanhevanh Posts: 15,126
    edited 2019-09-19 20:57
    With XDIVP = 1, below something like 25 MHz on the revB PLL can be extreme (high XDIVs are worse), big jumps in jitter, easy bad enough to corrupt serial comms. 20-21 MHz is a particular bad spot, maybe related to the 20 MHz crystal frequency. 10 MHz and lower is a pile of potholes.


    Here's a screenshot of a very stable clock on the revB Eval board running 400 MHz sysclock producing a 1 MHz square wave on pin0. The trigger point is first rising edge at 5% position. The bottom half of the display is 20x zoom of the top half showing the final low going transition in detail at 10 ns/div. What isn't obvious at first glance is scope's sampling hardware is 200 MS/s (Mega Samples per second). But at the top it says 50 GS/s. What's going on is it actually triggers on many cycles of the "repeating" square wave to progressively build small pieces of the total 100,000 samples. The timing is accurate enough to emulate all the intervening samples needed for 50 GS/s effective ... provided the signal keeps repeating exactly the same all the time. So, if there was any jitter, over what is a relatively large time period, then it would splatter the display.
    XDIV = 10
    XMUL = 200
    XDIVP = 1
    pin_lat0166.PNG
    640 x 480 - 9K
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-09-19 20:46
    Impressive scope Evan.
    What initial divider and multiplier are you using?

    With Rev1 silicon jitter was more apparent the lower the base frequency ie the lower frequency after the first divider. This resulted in a higher poll multiplier which seemed to be the culprit.
    When I divided the crystal down to 0.5MHz, multiply by 297 and final divide by 1 there was a lot of jitter on the vga running 148.5MHz. But when using the base as 3MHz, multiplier of 99, and final divide by 2 it was way more stable.
  • evanhevanh Posts: 15,126
    edited 2019-09-19 21:12
    PS: I've added the HUBSET mode config to the above post.

    And here's what the same revB chip looks like with a comport corrupting rough result at 20.5 MHz sysclock. The comport actually still worked!
    XDIV = 40
    XMUL = 41
    XDIVP = 1
    pin_lat0172.PNG


    And this one, on same revB chip, is same 20.5 MHz sysclock but the PLL is up at 123 MHz so all is good again.
    XDIV = 40
    XMUL = 246
    XDIVP = 6
    pin_lat0173.PNG
    640 x 480 - 12K
    640 x 480 - 9K
  • evanhevanh Posts: 15,126
    Cluso99 wrote: »
    With Rev1 silicon jitter was more apparent the lower the base frequency ie the lower frequency after the first divider.
    It looks like it's more mixed than that too. On the revA chip, the scope is telling me XDIV of 5, 7 and 17 are also a problem. It comes and goes from 20 and up.
  • roglohrogloh Posts: 5,122
    edited 2019-09-20 00:30
    @garryj we should also check USB works with 270MHz operation too as that allows HDTV resolutions over HDMI instead of VGA.

    Yes, TonyB and JRetSapDoog, I agree that 252MHz would be better for sending VGA over DVI/HDMI, not 250MHz. 250MHz happened to be the frequency setup in the Chip's original HDMI demo code and it worked on my setup, though officially VGA is meant to be using a pixel rate of 25.175MHz in the specs. Being as close as possible to official VGA timing should help a larger range of display devices be supported by P2s, in particular HDTVs.

  • jmgjmg Posts: 15,140
    evanh wrote: »

    The revB chip is solid above 80 MHz on the PLL (pre-XDIVP), it progressively gets jittery lower down so we definitely need to exercise XDIVP from now on.
    That’s largely expected - at lowest MHz the VCO is being very voltage starved, so will quickly deteriorate.
    Most MCU vendors give some MHz band for VCO correct operation.

    I think you are saying at no point is Rev B worse than Rev A, which is good to hear ?
  • rogloh wrote: »
    @garryj we should also check USB works with 270MHz operation too as that allows HDTV resolutions over HDMI instead of VGA.
    Didn't see any issues at 270MHz.

    Not much progress regarding the 148.5MHz issue. At 148MHz and 149MHz there is no "frame jitter". At 148.5MHz the USB data transfers are clean, too -- squeaky clean. The "frame jitter" complaints all happen when the host/driver is polling the device for mouse/keyboard changes. When no data is available the device will issue an IN-NAK packet, and there are lots of them. The keyboard driver keeps a NAK count to trigger key auto-repeat, so they're almost used like a strobe. There may be something the analyzer sees during this exchange that I don't yet understand. But at this stage, whatever it is that the analyzer doesn't like is not having any affect on data transfers. Since the USB has its own NCO, maybe there's some subtle timing differences that show up at certain sysclock/USB pairings?
  • roglohrogloh Posts: 5,122
    edited 2019-09-20 06:24
    Today I played around with the frequencies of the revision B P2 and managed to drive my HDTV over an HDMI cable with it clocking at 270MHz. The resolution is 720x480@60Hz (480p60) which is an official TV resolution with a pixel rate of 27MHz. My Pioneer plasma recognized it and scaled accordingly.

    I have just used the same test image from Chip's demo which is only 640x350 16bpp but I padded it with 40 pixels of red and green at the sides using immediate mode output to make up the 720 pixel width until I find/make a nicer test image that is already 720 pixels wide. The garbage at the bottom is when the streamer runs out of valid image pixels in hub RAM. Obviously it needs more RAM for holding an entire frame buffer at this resolution and 16bpp colour depth.

    hdtv.jpg

    I'd quite like to look at that HyperRAM board soon and see if I can stream some pixel data out of it. The problem I see is that this particular HyperRAM only runs at up to 100MHz (200MB/s DDR) but ideally for a frame buffer we might like to clock it at 135MHz (or 126MHz for VGA) as that would be half of the P2 system clock used at these video output resolutions. It now seems like it will have to be clocked at only a quarter of the P2 clock, or 67.5MHz / 63MHz instead, which probably gets you transfers in the vicinity of 120MB/s depending on burst length. It would be much better if the RAM was rated to clock up to ~133MHz at 3.3V but for hitting that RAM clock speed right now you need to operate it at 1.8V. Streaming from this HyperRAM at ~120MB/s after overheads should still support 27M pixels per second at 480p60 using a 32 bit aligned truecolor pixel layout in memory (which is somewhat wasteful) but then it has minimal memory bandwidth remaining for any other read/writes. Using a 16bpp mode instead would leave you approximately half the bandwidth for any other reads/writes and is likely the better choice, or you could even go down to 8 bit colour. Maybe we could gang up two HyperRAMs to effectively make a 16 bit bus instead of an 8 bit bus for faster transfers with the higher colour depths. I wonder if they could then share clocks and chip selects and run from one single COG? Or you could run them individually on a COG each I guess.

    Some of the simple tweaks I used with Chip's demo code for getting this video resolution:
            hubset  ##%1_000001_0000011010_1111_10_00   'configure PLL, 20MHz / 2 * 27 * 1 = 270MHz
    ...
            callpa  #25,#blank      'top blanks
    
            mov     x,##480         'set visible lines
    line        call    #hsync          'do horizontal sync
            xcont   m_frame,color1
            xcont   m_rf,#1        'do visible line
            xcont   m_frame,color2
            djnz    x,#line             'another line?
    
            callpa  #18,#blank      'bottom blanks
    ...
    color1      long    %1011110000_0111110000_0111110000_10 - red(ish)
    color2      long    %0111110000_1011110000_0111110000_10 - green(ish)
    
    m_frame     long    $7F910000+40        'frame borders 40 pixels
    m_bs        long    $7F910000+32        'before sync
    m_sn        long    $7F910000+64        'sync
    m_bv        long    $7F910000+42        'before visible
    m_vi        long    $7F910000+720       'visible
    
    m_rf        long    $BF950000+640       'visible rfword rgb16 (5:6:5)
    
    800 x 600 - 92K
  • evanhevanh Posts: 15,126
    jmg wrote: »
    That’s largely expected - at lowest MHz the VCO is being very voltage starved, so will quickly deteriorate.
    Most MCU vendors give some MHz band for VCO correct operation.

    I think you are saying at no point is Rev B worse than Rev A, which is good to hear
    Yep. Although, it's the first time I've done this so I'm kind of giving a running commentary of my discovery at the same time.

  • evanhevanh Posts: 15,126
    rogloh wrote: »
    Today I played around with the frequencies of the revision B P2 and managed to drive my HDTV over an HDMI cable with it clocking at 270MHz. The resolution is 720x480@60Hz (480p60) ...
    Great mode choice. Not pushing too hard on the overclocking and is a good reliable fit mode wise. Pixel doubling of that for games would be the way to go.

    ... It would be much better if the RAM was rated to clock up to ~133MHz at 3.3V but for hitting that RAM clock speed right now you need to operate it at 1.8V.
    Baby steps. Get that going then see what happens with the RAM clock doubled. It may not complain at all.

  • TubularTubular Posts: 4,620
    edited 2019-09-20 06:07
    Whats interesting with the Hyperram spec is that at 1v8, they spec 100, 133 or 166 MHz operation.

    By the time you're at 3v0 you've only got 100 MHz operation available. I wonder what the midpoint voltage is, where 133 MHz still works? Could we be lucky at 2v5?

    Chip has said previously that I/O would be slow and weak at 1v8 VIO, but perhaps there is some compromise in the middle. Not trying to distract from the excellent testing... just an observation

  • Tubular wrote: »
    Whats interesting with the Hyperram spec is that at 1v8, they spec 100, 133 or 166 MHz operation.

    By the time you're at 3v0 you've only got 100 MHz operation available. I wonder what the midpoint voltage is, where 133 MHz still works? Could we be lucky at 2v5?

    Chip has said previously that I/O would be slow and weak at 1v8 VIO, but perhaps there is some compromise in the middle. Not trying to distract from the excellent testing... just an observation

    That's a good point. We thought about adding an LDO to run the memory just above the P2's IO logic threshold voltage, but for demo and development decided to keep things as simple and standard as possible, especially as the possibility exists to use up to 3 of these hyper mem breakouts for experimenting with 2x or 3x faster access to data; and that nicely demos the abilities of cogs too.

    So yes, tweaking vcc is one option, or multiple modules another.

    Another thing about the hyper breakout pcb is that dual ram could be used instead of 1ram, 1flash. That would need an intrepid user with a hot air gun, but it's another option too! Maybe if there's enough demand, Parallax might be able to stock that configuration.
  • Looks good Roger. :)
Sign In or Register to comment.