Shop OBEX P1 Docs P2 Docs Learn Events
Rev.B Silicon examples with PNut? — Parallax Forums

Rev.B Silicon examples with PNut?

RaymanRayman Posts: 14,646
edited 2019-11-13 20:20 in Propeller 2
I got my Rev.B board here, but I'm off to a slow start...
Is there a new version of PNut that we need to use with Rev.B?
Is there a revised set of examples, like what used to come with each FPGA release, out there somewhere?

Was there a list of things you need to change in code to update from Rev.A to Rev.B?

My Rev.A codes don't work and can't figure out why...

Comments

  • Dave HeinDave Hein Posts: 6,347
    The thread at https://forums.parallax.com/discussion/169695/new-fpga-files-for-next-silicon-version-5th-final-release-contains-new-rom/p1 has a link to the zip file for v33k, which I believe is the latest version. The zip file contains PNut and example programs.
  • RaymanRayman Posts: 14,646
    Thanks, that helps!
  • ersmithersmith Posts: 6,053
    My VGA driver at https://github.com/totalspectrum/p2_vga_text has an example of how to dynamically handle the differences between RevA and RevB video setup. If you look at the start method in vga_tile_driver.spin2 you'll see how I poke some different values into the streamer constants in the COG code before starting that up, and the check_hw_rev method shows how to detect RevA vs. RevB at run time (probably not the most elegant way, but it works).
  • RaymanRayman Posts: 14,646
    Thanks, that helps.
    Are the clock settings still the same?
  • ersmithersmith Posts: 6,053
    Rayman wrote: »
    Thanks, that helps.
    Are the clock settings still the same?

    For VGA? My driver takes the clock settings as parameters, or rather it takes the ratio of the system clock and pixel clock as a parameter and it leaves the system clock unchanged.

    But in general I don't think anything changed in the clock mode bits in RevB, so that part of your existing code should be OK.
  • evanhevanh Posts: 15,916
    edited 2019-11-14 02:05
    Sysclock config is same, yes. Only difference is it's now a good idea to make use of XDIVP when targetting below 80 MHz. Which also means that minimum stable sysclock with PLL selected is about 2 MHz.

    EDIT: I'd like to know if a different crystal frequency affects the PLL's bad spot. With the Eval board it has bad jitter around 20 to 21 MHz (XDIVP = 1).
  • jmgjmg Posts: 15,173
    evanh wrote: »
    Sysclock config is same, yes. Only difference is it's now a good idea to make use of XDIVP when targetting below 80 MHz. Which also means that minimum stable sysclock with PLL selected is about 2 MHz.

    EDIT: I'd like to know if a different crystal frequency affects the PLL's bad spot. With the Eval board it has bad jitter around 20 to 21 MHz (XDIVP = 1).

    That's likely the VCO running very much current starved, and I'd expect Xtal to not effect that much.
    A higher PFD would help, by providing more frequent updates, but the close-in noise would be what it is...
    I've noticed SiLabs ClockBuilder always trends to highest VCO / Highest PFD MHz in their calculations, as that will give the least jitter.
    For someone wanting lowish SysCLKS, they could always use a direct feed from a higher MHz Osc or Xtal.

    I tested 38.4MHz Clipped Sine feed into EvalA, and that seemed to work fine, but was showing signs of gain fall-off.
    Not sure what the highest MHz Cystal P2 can support is, (will be at lowest CL setting) & Parallax should test and specify that.
    With other vendors 25~32~36MHz are common max for Crystal Osc working , but those also depend on ESR of the Xtal.
    The External Clock in limit to P2 will likely be > 100MHz, and oscillators to 48/50/52MHz are common and low cost, with up to 100~125MHz available, but with generally not highest precision.

  • evanhevanh Posts: 15,916
    edited 2019-11-14 01:06
    Err, it's either side of 20 MHz is bad. So the question is what happens if the crystal frequency is different?

    EDIT: And it seems like the larger XDIV is, the worse it gets. eg: With XDIV = 10 there's no bad spots.
    EDIT2: Oh, that's right, the revA silicon had unstable XDIV's of 5, 7, 17, 20, and lots above that. Those affected the whole spectrum though ...
    EDIT3: XDIV = 5 is one of the most stable of all on the revB. It's fine right down at XMUL = 1.
    EDIT4: XDIV = 7 is good, 17 pretty good - showing weakness around 21 MHz. Inline with earlier observations of it's worse as XDIV gets bigger. 16 is same for example.

    EDIT5: I think I'll revise the minimum generalised stable down to 40 MHz (XDIVP = 1). The earlier 80 MHz recommend looks a tad conservative.
  • RaymanRayman Posts: 14,646
    edited 2019-11-14 00:43
    Ok, I feel better now... Am able to get VGA going again...

    Only this section is changed: 
    m_bs        long    $7F010000+16        'before sync
m_sn        long    $7F010000+96        'sync
m_bv        long    $7F010000+48        'before visible
m_vi        long    $7F010000+640       'visible

m_rf        long    $7F080000+640       'visible rlong 8bpp lut
    spin2
    spin2
    VGA_640_x_480_8bpp_ray.spin2
    5K
  • evanhevanh Posts: 15,916
    edited 2019-11-14 03:56
    Rayman wrote: »
    Only this section is changed:
    Yeah, all the streamer mode constants have changed in revB. It's trickier trying to automatically handle the differences with encoding mode word sizes and endianness.
  • evanhevanh Posts: 15,916
    edited 2019-11-14 05:26
    evanh wrote: »
    XDIV = 5 is one of the most stable of all on the revB. It's fine right down at XMUL = 1.
    Struck an oddity: When both XMUL = 1 and XDIVP = 1 then XDIV > 5 will freeze the prop2.

    XDIV = 5 tested from -4 °C to 90 °C and looked very stable throughout while cycling through smallest XMUL values. XDIV = 6 mostly works below 20 °C, may have glitches. Anything higher is instant lock-up.

    Raise XDIVP to two and the lock-ups vanish entirely. EDIT: I guess this is partly due to the PLL being incredibly unstable at such low target. The jitter is enormous with XDIV of 60 and XMUL of 20, say.
  • jmgjmg Posts: 15,173
    evanh wrote: »
    evanh wrote: »
    XDIV = 5 is one of the most stable of all on the revB. It's fine right down at XMUL = 1.
    Struck an oddity: When both XMUL = 1 and XDIVP = 1 then XDIV > 5 will freeze the prop2.

    XDIV = 5 tested from -4 °C to 90 °C and looked very stable throughout while cycling through smallest XMUL values. XDIV = 6 mostly works below 20 °C, may have glitches. Anything higher is instant lock-up.

    Raise XDIVP to two and the lock-ups vanish entirely. EDIT: I guess this is partly due to the PLL being incredibly unstable at such low target. The jitter is enormous with XDIV of 60 and XMUL of 20, say.

    Can you relate those back to the DOCs use of %DDDDDD %MMMMMMMMMM %PPPP ?
  • evanhevanh Posts: 15,916
    edited 2019-11-14 08:22
    %D is XDIV
    %M is XMUL
    %P is XDIVP

    The naming is from Cluso's handy config constants from a year ago - https://forums.parallax.com/discussion/comment/1452025/#Comment_1452025

  • jmgjmg Posts: 15,173
    evanh wrote: »
    evanh wrote: »
    XDIV = 5 is one of the most stable of all on the revB. It's fine right down at XMUL = 1.
    Struck an oddity: When both XMUL = 1 and XDIVP = 1 then XDIV > 5 will freeze the prop2.
    %D is XDIV %M is XMUL %P is XDIVP

    So that means you are asking a 20MHz Xtal to give a 4MHz (!) VCO ? That's way outside the 100MHz min spec Chip gives ?


  • evanhevanh Posts: 15,916
    edited 2019-11-14 09:13
    Yup. Wasn't expecting anything good when I tried those combinations but that particular one came out amazingly stable. :)

Sign In or Register to comment.