HyperRAM Solutions for P2 (and P1)

2»

Comments

  • Thanks Cluso

    here's the short clip. When you get back to Oz I'd be keen to talk to you about your SMT soldering setup
  • I just tried looking at that clip on a Mac and it's badly corrupted up to the 17s mark using QuickTime Player. It was made on a PC - will investigate tomorrow

    Sorry about that
  • Just tried Macgo, a freeware MacMedia player and it shows the video ok on my MacBook Pro - hope that helps
  • evanhevanh Posts: 3,960
    I've whipped it through Handbrake, give this a try.
    $50,000 buys you a discrediting of a journalist
  • Evanh - yes that's sorted out the problem running Quicktime - thanks
  • RJSM wrote: »
    Thanks Cluso

    here's the short clip. When you get back to Oz I'd be keen to talk to you about your SMT soldering setup
    email or PM me end of next week in case I forget ;)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Very nice work Richard! :)
    Melbourne, Australia
  • YanomaniYanomani Posts: 371
    edited June 5 Vote Up0Vote Down
    deleted
  • Hi RJSM
    RJSM wrote: »
    Hi Henrique

    Great timing diagram !

    Some clarification - In my code CR0 and CR1 are configured just once on program startup

    Here are the 8 bytes (hex) I’m writing to each register :
    CR0 : 60 00 01 00 00 00 AF E8
    CR1 : 60 00 01 00 00 01 00 02

    The E8 in the CR0 data stream configures HR for 3 clock latency and also requests a fixed 2x latency. Doing that seems desirable, simplifying the need to explicitly handle RWDS apart from a direction change before sending data. As far as the clock is concerned, all is as in your timing diagram.

    In my file WR_HR.jpg, I’m not accessing CR0 – in the LA traces you’ll see that prior to the 1st clock rising edge DQ5 is set high - unfortunately I did not capture DQ6 here - which would have made this clearer as it would have been low ie my first data byte sent is $20 and not $60 which would indeed have been a register access.

    On the question of the long duration of my RWDS I find the datasheet unclear regarding exactly when one should make RWDS an output. In HR_WR, after setting up the streamer and smart pin, then pulling CS low (with RWDS initially configured as an input pin), I’ve got the following lines in my code to change RWDS direction and pull it low (to ensure there’s no data masking) :

    waitx #n
    drvl #HR_RWDS

    In WR_HR.jpg my delay cycles constant n was rather large and I’ve reduced it – now RWDS is high exactly as shown in your timing diagram. In the case of a RD_HR there is no need to change the direction of that pin, of course; it’s an input. Good to have that sorted out thanks to your input.

    In a couple of minutes i'll post code (now with some documentation) and a short video clip as well


    First, I must acknowledge your excellent work, both in hardware and software, and express how much I personally thank you by sharing it with us.

    Without it, we wouldn't had a real chance to discuss and share our efforts, on such an important and urgeing subject as the parallel comms.

    Since the last opportunity, I've crafted a new write transaction panorama image, now focusing Fclk = 120 MHz and an edited copy of your original table, with the missing 8 in place, I hope.

    It spans from transaction's starting #CS low-going pulse, till the high-going ending one and depicts the three zones I've used to part the time spent at P2/HyperRam interface, during write accesses to HyperRam .

    Clocks, control signals data buses contents and individual bit lane values, for CA's group and the sixteen originally intended data bytes, are shown in a LA-style display format.

    Let me post it, then further comments can be shared.

    Henrique

  • YanomaniYanomani Posts: 371
    edited June 5 Vote Up0Vote Down
    Hi RJSM

    An expanded view of the same image, this time showing bus tags/values.

    Excluding CA[8] (bit lane D0 value at CK's third rising edge, during CA phase) that should be 0 (tagged as "Reserved" at ISSI datasheet Rev. A 06/28/2016, page 6), they behave like identical twins.

    I've restricted the transaction plot to 16 data bytes to spare the obvious repeating frames.

    More on the go... :lol: :lol:

    Henrique

    Curio_P2_WR_Sixteen_CS_to_CS_Expanded.png
  • Nice work. 50 MB/s is pretty good.
    I'll have to see if this works on my board...

    BTW: I don't know if this is new or not, but I just noticed a chip with both HyperRAM and HyperFlash in one package. $16 though...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 10,208
    RJSM wrote: »
    I'll post my effort on a P1 HyperRAM test in a week or so in that area of the forum. It still needs extensive documentation. Would be sooner - but a kitchen renovation here is making this slow-going !
    Curious for any updates on this ?
  • jmgjmg Posts: 10,208
    jmg wrote: »
    Because the 4us is a royal pain, I've been running a pencil over self-refresh, with a view to a simple direct P1 <-> HyperRAM(s) -> LCD Display connection.
    The LCD has an DE line, and needs parallel up to 24b, giving choices of 1,2 or 3 HyperRAMs connected.
    With no DE, the data is ignored, so refresh or write can be done anytime DE is inactive. (more forgiving that VGA)

    I think a P1 can read continually readily enough, and so that handles refresh the RAM of the displayed frame.

    Further to this, I've been looking into MCU -> HyperRAM -> 24b LCD.
    Yes, 2 or 3 HyperRAM is possible, but whilst they are somewhat cheap ($1.65/1k), they are not free, and that still needs 24+ pins write pathway.
    Smarter seem to be ONE HyperRAM, as that is already very large in Pixel count.

    So, I've looked at smaller CPLDs to 'see what can fit'.
    These are TQFP44, ~$1.30/1k, and you need just 1, and it gives an 8b path to host MCU.
    Once the LCD data path is there, I iterate to 'do more' in the CPLD, so the MCU has to do less.
    There are pin limits on this, as 24b LCD and 8b HR leaves just 4 control/signal lines.

    This is LCD data I've used :
    Horiz : 800, Vert 480, LCD_CLK typ 30MHz, Max 50MHz
    HORIZ DE Blanking 85 < 128 < 512 DCLK - tH
    VERT DE Blanking, 4 < 45 < 255 tH

    This data has min and max for the blanking, so you need eg 800+(85..512) clocks per line.

    CPLD currently takes 2 words on 4 edges, and latches 24b to LCD bus, and checks the spare 8b for command codes/tags.

    Latest rev derives LCD_DE from embedded codes, which slashes MCU overhead into a single playback clock burst
    (but does mean you do need to initially insert those tags, and memory is a little larger than simple pixel space)

    A mode bit allows CPLD(auto) or MCU(manual) control of LCD_DE, so that for early testing, and Fast-Fills/Erase the LCD can work with no tags yet.

    Helping this, is the recent better availability of 60,72,80 MHz region oscillators, HR_CLK is 2x LCD_CLK
    Starting lower Mhz end is probably smarter.

  • P2 HyperRAM project - progress update

    I’ve now populated 2 new OSHPark PCB’s – one targeting HyperRAM for P1 and the other for P2.

    The P2 version is just a small breakout PCB that plugs into the prototyping area of the Parallax add-on board for the DE2-115. The HR chip is then connected to P11…0 via hookup wires – light blue for the data bus and yellow for the control signals.

    The resistor you see in the photo is 56 ohms - this is placed in the CLK line from P9 – and proved essential in getting reliable performance with this setup (see the validation test below).

    Aside : I could have made a P2 PCB with a double row header to plug directly into the I/O connector on the add-on board (which would have meant more direct inter-connections to the HR chip) - but I ended up going with this arrangement for a bit more flexibility.

    For testing, I’ve added a new command (Q) to my code to access the full 8MB of HyperRAM as 65536 blocks, each of 128 bytes.

    Here’s what I implemented for a validation test [timings in usec] :

    Initialize block counter
    * Fill 128 byte buffer with random bytes (using XORO32) [30.4 usec]
    Write this buffer to HR [3.0 usec]
    Read the buffer back from HR [3.0 usec]
    Compare write and read buffers, maintaining an error counter [33.5 usec]
    Decrement block counter and repeat at * till done

    Total time per 128 byte buffer here is 70 usec, most of which is taken up generating the random numbers and comparing the write/read buffers.

    I’ve just finished running this code continuously for ~24 hours and during that time ~150 gigabytes of random data were transferred to/from HR - without a single error.

    Wanted to post this info now as I’ll soon be travelling for an extended period of time (until early September) without access to P1/P2 projects.
  • Can someone please clarify the mode of operation of the XORO32 instruction ?

    Chip’s May 23 post re XORO32, seems at odds with what’s documented in the latest v20.xlsx instruction spreadsheet, which states -

    “Iterate D with xoroshiro32+ algorithm. Top 1..15 bits of sum of low and high words are high-quality pseudo-random data.”

    The code I just posted was based on Chip's May 23 information. I did look at the random data being generated and superficially it seems ok - but then I can’t claim I did any rigorous mathematical testing of the randomness of the data.
    750 x 110 - 31K
  • jmgjmg Posts: 10,208
    edited July 18 Vote Up0Vote Down
    Cool.
    RJSM wrote: »
    For testing, I’ve added a new command (Q) to my code to access the full 8MB of HyperRAM as 65536 blocks, each of 128 bytes.
    It could also be useful to access as row * column sizes. (eg 8192 x 512 words)
    RJSM wrote: »
    Here’s what I implemented for a validation test [timings in usec] :
    Initialize block counter
    * Fill 128 byte buffer with random bytes (using XORO32) [30.4 usec]
    Write this buffer to HR [3.0 usec]
    Read the buffer back from HR [3.0 usec]
    Compare write and read buffers, maintaining an error counter [33.5 usec]
    Decrement block counter and repeat at * till done

    Total time per 128 byte buffer here is 70 usec, most of which is taken up generating the random numbers and comparing the write/read buffers.

    I’ve just finished running this code continuously for ~24 hours and during that time ~150 gigabytes of random data were transferred to/from HR - without a single error.
    Nice test.
    Can you increase the buffer size to larger values ?
    Useful would be line-buffer of say 3200 bytes / 1600 words, and frame buffer times of ~ 30ms.

    Refresh spec is > 64ms, so it could also be useful to look for the typical needed - ie place a delay between Write and Read, and increment slowly until Read failures appear.

    It probably does not need to be true random, just 'not the same as last time'.
    I've used a simple (address upper XOR address lower) to get a rolling and moving memory offset test pattern.

  • RJSM wrote: »
    Can someone please clarify the mode of operation of the XORO32 instruction ?

    Chip’s May 23 post re XORO32, seems at odds with what’s documented in the latest v20.xlsx instruction spreadsheet, which states -

    “Iterate D with xoroshiro32+ algorithm. Top 1..15 bits of sum of low and high words are high-quality pseudo-random data.”

    The code I just posted was based on Chip's May 23 information. I did look at the random data being generated and superficially it seems ok - but then I can’t claim I did any rigorous mathematical testing of the randomness of the data.

    Ah, I see now, having been alongside Chip for a part of this one little corner, I had to read and compare and reread both Chip's earlier postings and the instruction description to finally get to where your question is coming from. The instruction description reads like the summing is done by the instruction when it most definitely doesn't do that part. The summing is outside the iterator section so it's easy to leave out and of course that saves a decent amount of logic.

    The 1 to 15 bits of useful HQ output is just too dense detail, out of context even, for one line of text. The second sentence of the instruction description probably should just say it's used for high quality but tiny PRNG.

    Here's a good place read on the workings of the xoro32 instruction - http://forums.parallax.com/discussion/comment/1409681/#Comment_1409681
    $50,000 buys you a discrediting of a journalist
Sign In or Register to comment.