HyperRAM data (64MBit) now available

With just 12 interface lines, this looks an ideal match to a Pin-Constrained P2 package.It may even work with P1V.
http://www.spansion.com/Products/memory/HyperRAM-Memory/Pages/Spansion KL.aspx

http://www.spansion.com/Support/Datasheets/S27KS_KL-S_PB.pdf
They appear to have some strange constraints on auto-refresh windows, but then they say ["The host system may also effectively increase the tCMS value by explicitly taking responsibility for performing all refresh and doing burst refresh reading of multiple sequential rows in order to catch up on distributed refreshes missed by longer transactions."]
["Table 5.7 Array Refresh Interval per Temperature
Device Temperature (°C) Array Refresh Interval
(ms) Array Rows Recommended tCMS (µs)              85 64         8192                    4             105                         16         8192                    1
A 60Hz video scan, is well inside 85°C spec, and reaches almost to the 105°C corner, and should refresh-as-scanned (but limits RAM usage to the displayed area).

There looks to be a simple linear streaming read mode, similar to QuadSPI parts, which is well suited to Video streaming / Buffering.
[" Linear transactions are generally used for large contiguous data transfers such as graphic
image moves. When configured in linear burst mode, the device will automatically fetch the next sequential row from the memory array to support a continuous linear burst. Simultaneously accessing the next row in the array while the read or write data transfer is in progress, allows for a linear sequential burst operation that can provide a sustained data rate of 333 MB/s (1 byte (8 bit data bus) * 2
(data clock edges) * 166 MHz = 333 MB/s)."]
and this sounds like a possible fish-hook, but there seems a way to force fixed latency ?["In the event a distributed refresh is required at the time a Memory Space read or write transaction or Register Space read transaction begins, the RWDS signal goes high during the Command-Address to indicate that an additional initial latency is being inserted to allow a refresh operation to complete before opening the selected row"]

Comments

  • 9 Comments sorted by Date Added Votes
  • So what we now need is a small board with both a HyperFlash and HyperRam attached somewhat in parallel like they allude to.   
    Any idea how easy samples are to come by yet, jmg?
  • So what we now need is a small board with both a HyperFlash and HyperRam attached somewhat in parallel like they allude to.   
    Any idea how easy samples are to come by yet, jmg?

    The releases claim Q2, but they tend to all be 'future tense', so would need to ask Spansion.HyperFLASH is less interesting, as I'd still see a Prop2 booting from SPI Flash.The HyperRAM data is quite poorly written and contradicts.They mention user-refresh, but I cannot see a mode that increment rows on each clock, which is the natural method to do this, Without that, it costs 10+ clocks and a lot of shuffling, to user refresh each row, one at a time..
    The examples all show CLK active only during CS low, but they talk about auto-refresh, and there the expected operation is to inc ROW on every clk when inactive.Their strange specs hint at some sort of leading edge steal, where a limited stolen cycle is used to refresh, and that is flagged to the host. Quite a round about method.They DO have a linear continual read, which is nice.
  • That's a hell of a constraint.  At least they are detailing the problem.   Maybe that is why they have delayed release?  For the P1 no problem.  It is a matter of pin count.  I don't know the market.  But if there is one... fine.   For the P2... it will beat that memory to death... have it sucking wind to trying to keep up. 

    I looked at this a while back... and I seem to remember another issue having to do with the proprietary nature of the hyperbus... if that is the right issue.  There was something there that had to do with licensing control.  At the time my impression was that it would only affect corporate customers... but there was something... don't remember exactly and don't know where to look now.  It was a while ago and given the delays and issues maybe it has changed.
  • jmgjmg Posts: 9,299
    edited September 2015 Vote Up0Vote Down
    Tubular wrote: »
    So what we now need is a small board with both a HyperFlash and HyperRam attached somewhat in parallel like they allude to.
    Any idea how easy samples are to come by yet, jmg?

    I now see a post 2 months ago by Antti claiming 40 samples of HyperRAM S27KS0641
    https://hackaday.io/project/3487-artixon

    Also shows a PCB for FPGA and HyperRAM and Serial Flash, so FPGA code to talk to HyperRAM should be close ?

    I also see Microchip have new RAM-based MCUs that boot over Intel's new eSPI, which is a QuadSPI bus spec'd for 66MHz, to replace their older LPC ( not sure if DDR? )
    http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=enew5458
    MEC1418 has 192k SRAM and they indicate $2.16/5k - targets PC IO uses, so has a modest MHz PIC32 core.
  • I made a PCB for these plus USB and some other stuff a while ago:
    http://forums.parallax.com/discussion/164540/

    I got it talking, but then decided with 4bpp and 480p-like resolutions, the 512kB of P2 is good enough and it isn't really needed.

    But, still might make a nice video buffer for better graphics down the line...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    I made a PCB for these plus USB and some other stuff a while ago:
    http://forums.parallax.com/discussion/164540/

    I got it talking, but then decided with 4bpp and 480p-like resolutions, the 512kB of P2 is good enough and it isn't really needed.

    But, still might make a nice video buffer for better graphics down the line...


    For bigger-system apps, those HyperRAM chips are going to be awesome. And vital.

    It would be important to know if the streamer works smoothly with HyperRAM. The advent of HyperRAM is a really big deal for the Prop2.


  • I thought about trying it as a screen buffer. But, the more I thought about it, the more complex it seemed to be... Have to juggle outputting to screen and updating screen.
    I think the bandwidth is there to do it, just would take some time to develop...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 9,299
    edited December 2016 Vote Up0Vote Down
    cgracey wrote: »
    For bigger-system apps, those HyperRAM chips are going to be awesome. And vital.

    It would be important to know if the streamer works smoothly with HyperRAM. The advent of HyperRAM is a really big deal for the Prop2.

    Yup, and I see also now there is now also Flash and HyperRAM in one package.
    S71KL512SC0BHV000 512Mb FLASH 64Mb DRAM 24FBGA 0 $14.28
    Rayman wrote: »
    I thought about trying it as a screen buffer. But, the more I thought about it, the more complex it seemed to be... Have to juggle outputting to screen and updating screen.
    I think the bandwidth is there to do it, just would take some time to develop...

    I think there are a couple of stages this could be developed in.

    Simplest is to CLK stream HyperRAM, maybe with a simple external LVC octal buffer for VGA drive and for blanking during write, and less overall pins.
    Updates are then during blanking times. This structure would work even on P1?.
    However, there are trade offs with this - you are using the reads as refresh, so only the active image is refreshed.
    For many uses, that is tolerable. Parts are cheap and small.

    For LCD and not VGA drive, there may be more tolerance in stretching blanking times, and adding refresh gaps to reads, but VGA type raster testing would be easy initially.

    Next step is to line-buffer, so that interleaved WR/RD can be done, but this is trickier with more balls in the air.
    The link above includes this "HyperRAM™ Refresh Interval Optimization"
    http://www.cypress.com/file/215416/download
    which shows how many bytes per-refresh pause are possible, but those are at full chip speed.

    It's a pity they did not include a refresh wrap option, to trade off size with time, or manage to stretch refresh gaps to more common flyback times.
    Maybe future models will tune like this ? Other brand variants are coming.
Sign In or Register to comment.