Shop Learn
Memory drivers for P2 - PSRAM/SRAM/HyperRAM (was HyperRAM driver for P2) - Page 31 — Parallax Forums

Memory drivers for P2 - PSRAM/SRAM/HyperRAM (was HyperRAM driver for P2)

1252627282931»

Comments

  • MaciekMaciek Posts: 526
    edited 2021-09-21 12:41

    Looks like the P2 chip or the software is the reason for it, not the board and that's good to know :).
    To be honest, I suspected it from the start when you described the problem but I'm glad I kept my mouth shut until now. I'll test my KISS boards this weekend too.

    EDIT: ok, I saw the post in the KISS thread ten seconds ago - looks like it's even better. The software can be corrected/polished far more easy than the silicon.

  • @Scroungre said:
    Better! But not quite perfect... I cut and pasted your "PRI computeClockMode(desiredHz)" code and replaced the old method with that, and it ran happily up to about 348MHz before complaining about a 'set RAM Delay failed'. See attached text.

    Error -6 is invalid arguments (ERR_INVALID). Looks like the delay parameter calculation it tries to make is invalid but it's weird because this means the parameter values passed are bad or some other data structure corruption. Maybe some HUB RAM accesses start getting corrupted at that high a frequency?

    ' method to set the delay value used in the driver for the memory device mapped to the address
    ' addr - address of the Hyper device to configure
    ' delay - nibble value passed is (delayClocks * 2) + (registeredDataBusFlag)
    ' returns 0 for success or negative error code
    PUB setDelay(addr, delay) : r
        if delay +> 15
            return ERR_INVALID
        r := modifyBankParams(addr, $FFFF0FFF, delay << 12)
    
    
    ' internal method modifies the bank specific parameters for the given addr and applies to the driver
    PRI modifyBankParams(addr, andmask, ormask) : r | bus, bank, value, size, i, m
        bus := addrMap[addr >> 28]
        if bus +> LAST_INSTANCE
            return ERR_INVALID
    
        ' driver must be running
        if driverCogs[bus] == -1
            return ERR_INACTIVE
    
        ' get starting bank and size used by this address
        bank := getStartBank(bus, addr)
        if bank < 0
            return ERR_INVALID
        size := devices[bus * 2 * NUMBANKS + bank] & $ff
    
        m := mailboxAddr[bus] + driverCogs[bus]*12
        repeat until LOCKTRY(driverlock)
        ' configure parameter(s) over all spanned banks and update local storage also
        repeat i from bank to bank + ((1<<(size - S_16MB)) - 1)
            value := (devices[bus * 2 * NUMBANKS + i] & andmask) | ormask
            long[m][1] := value
            long[m] := R_SETPARAMS + (i<<24) + cogid()
            repeat
                r := long[m]
            until r >= 0
            if r == 0
                devices[bus * 2 * NUMBANKS + i] := value
            else ' error case
                r := -r
                quit ' TODO: cleanup?, potentially leaves multi-banks in an inconsistent state
    
        LOCKREL(driverlock)
    
  • roglohrogloh Posts: 3,793
    edited 2021-09-21 13:14

    @Scroungre said:
    The PLL code (with the con block and the Compute Clock method results gave me exactly the same results as yours. (at 25MHz Xtal). S.

    PS - For grinsies, I tested out my other KISS (I had bought two) and lightly tweaked your PLL calculation numbers to run up to 360MHz. It did. See attached...

    Ok so it is working now with this code, or do you still see failures in the delay test using this code? EDIT: just read your other results. Looks like it works now. Why it failed before at 301MHz is a mystery though unless my posted PLL calculation code above was different from yours. I took it from the release 0.8 zip.

  • evanhevanh Posts: 12,202

    Most likely a software bug me thinks. Scroungre using the driver in unexpected way or something.

  • roglohrogloh Posts: 3,793
    edited 2021-09-21 23:56

    @evanh said:
    Most likely a software bug me thinks. Scroungre using the driver in unexpected way or something.

    Maybe. I can't make my version fail that way, so perhaps a compiler difference, or something else Scroungre might have modified causing it. Until I hear of some way to definitively reproduce this I will be assuming my code is okay for now.

  • ScroungreScroungre Posts: 147
    edited 2021-09-22 03:17

    Hm. Yeah, it does seem I've gotten behind the curve again on compilers - will update that.

    It's possible I've screwed it up - I know just enough spin2 to be dangerous with it. The "PLL" results were from your code in post 899, just to replicate those results - which I then edited a few numbers to see what it would get me at 360MHz, which I did.

    I will have to have a think about what happens at 348MHz in the memory read/write test when it tries to pick another delay.

    The code worked beautifully 'out-of-the-box' on my 20MHz Xtal P2 edge, even if the memory access was crap. Now I have a much better memory bus, but the code's giving me trouble. I'll bang on it a bit more on my own. Thanks much for putting all this energy into it for me. 's appreciated. S.

  • roglohrogloh Posts: 3,793
    edited 2021-09-22 04:17

    The 348MHz issue might be indicating a hub RAM corruption issue at that high a clock speed. I've not seen this in my setup when I test up to 350MHz. An invalid parameter error indicates something being passed or checked has a problem and is out of range. The COG mailbox is typically not even accessed at that point so it is not the driver COG failing to respond. I wonder if hub RAM read access is failing or something is getting corrupted in hub memory at that frequency. You could always modify your memory.spin2 to print out the reason when it finds the error in setDelay() or modifyBankParams(), getStartBank() etc. Just call SPIN2's send() method where it happens and print the memory contents etc. To me it looks like data corruption of delay or addrMap that would do that.

  • I'll have a go at it, but given my history of screwing things up, I'm not entirely enthusiastic about the idea. But it's the least I can do - your code did present intelligent error codes, which is more than I can say for some! I'll poke around quite a bit more on my end. S.

  • ErNaErNa Posts: 1,672

    To push the limits puts you into the risk to be pushed by the Limits😊

  • In time for the holidays I have just released an updated memory driver package (version 0.9b) now containing my PSRAM driver and some initial support for SRAM (experimental), as well as a few demos and tools showing what it can do, including frame buffer graphics that work with my video driver. Check it out in the first post of this thread. :smile:

    It has been primarily been tested with flexspin (5.9.3) and also some in PropellerTool (both 2.6.0 and 2.5.3).

  • roglohrogloh Posts: 3,793

    Just wrapped up the coding of a 4 bit PSRAM driver variant and am about to start testing it. This was MUCH simpler than the 16 bit variant and easier to fit in the COG as well. The memory addressing now matches the native storage size of the device so there is no need to read-modify-write all the various cases where individual bytes/words get written in longs (as was needed for the 16 bit variant used by the new P2 Edge board).

    Once this testing work is done I'll update the driver suite to include it. It should be useful for simple single PSRAM device setups with just 6 P2 pins. This includes my own Voyager board. Even though it has one quarter of the bandwidth and size as a 4 PSRAM device setup it should be able to provide sufficient bandwidth for simple 8bpp VGA and SVGA video frame buffers with VGA or HDMI outputs, or lower depths. If we're lucky, maybe even XGA @ 8bpp (DAC only) when the P2 is pushed to 325MHz, probably only with aligned 1kB blocks per scan line. TBD.

    In this single device configuration the raw memory bandwidth equals the P2 frequency / 4 MB/s.

  • roglohrogloh Posts: 3,793
    edited 2022-01-14 06:11

    My 4 bit PSRAM (single chip) driver seems to be working with VGA now. Still testing but happy to see this working already. P2 is running at 252MHz here. PSRAM is clocking out nibbles at 126MHz (or 63MB/s).

    Wow, SVGA and XGA also work at 8bpp. Neat! P2 is at 325MHz below.

    Ignore the ghosted text, the screen was updating rapidly while I took the photo.

  • TonyB_TonyB_ Posts: 1,808
    edited 2022-01-14 10:15

    @rogloh said:
    My 4 bit PSRAM (single chip) driver seems to be working with VGA now. Still testing but happy to see this working already. P2 is running at 252MHz here. PSRAM is clocking out nibbles at 126MHz (or 63MB/s).

    Based on this, whether or not multiple PSRAM chips are needed would often depend on size, not speed. How many MB in one chip?

  • roglohrogloh Posts: 3,793

    @TonyB_ said:
    How many MB in one chip?

    Commonly available serial (QPI) parts are up to 8 MB.

  • pik33pik33 Posts: 1,212
    edited 2022-01-14 18:19

    P2 is running at 252MHz here. PSRAM is clocking out nibbles at 126MHz (or 63MB/s).

    Is it restricted to clock/2 ? (I am thinking about 320/3... 960x540x8bpp needs about 32 MB/s... ) I have prepared a contraption with P2 Edge and a breakout board (this: https://www.parallax.com/product/p2-edge-80-pin-adapter-kit/ ) - I have several memory chips and these boards: https://botland.com.pl/przejsciowki-smd-dip/2742-przejsciowka-sop-na-dip-8-pin-10szt-5904422303907.html - I think about soldering the PSRAM to this board, and then solder this directly to the Edge adapter kit with as short connection as I can do....

  • roglohrogloh Posts: 3,793

    @pik33 said:
    Is it restricted to clock/2 ? (I am thinking about 320/3..

    Right now my code does a divide by 2 only but you could probably try to tweak the timing in the driver to try to experiment with that. Not too sure about the duty cycle for the divide by 3 clock, hopefully it would work although the data sheet says it should be in the 45-55% range. I was thinking about adding a divide by 4 option sometime in the future for people who didn't want to overclock their PSRAM at all.

  • YanomaniYanomani Posts: 1,328
    edited 2022-01-15 05:09

    Perhaps I'm losing something, but, up to the extent of my knowledge, the ways one can resort, in order to craft a "Sysclk/3" output-signal by using the smart pins (e.g.: mode %00100 = pulse/cycle output), meant to drive, says, the clock signal for external Ram chips(s), would result in a 33/66 duty cycle (or 66/33), whichever best fits, in order to ensure stable data in/out, to/from the Rams.

  • roglohrogloh Posts: 3,793

    Yeah @Yanomani that can be done, but it will violate the data sheet specs for clock signal duty cycle. Whether that matters in practice is TBD.

Sign In or Register to comment.