Shop OBEX P1 Docs P2 Docs Learn Events
HyperRAM data (64MBit) now available — Parallax Forums

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

  • 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?
  • jmgjmg Posts: 15,140
    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.
  • rjo__rjo__ Posts: 2,114
    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: 15,140
    edited 2015-09-05 03:48
    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.
  • RaymanRayman Posts: 13,805
    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...
  • cgraceycgracey Posts: 14,133
    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.


  • RaymanRayman Posts: 13,805
    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...
  • jmgjmg Posts: 15,140
    edited 2016-12-24 19:56
    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.
  • jmgjmg Posts: 15,140
    edited 2017-08-17 04:30
    I also see more are offering 8-bit BUS DTR memory....

    https://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=1527055

    "JSC, made known sampling of a new high-speed, self-refresh OctaRAM based on JSC's low-pin-count interface, which announced the industry's fastest Octa serial interface RAM, the OctaRAM JSC64SS product family."

    I also find
    http://www.macronix.com/en-us/products/NOR-Flash/Pages/OctaFlash.aspx#3V
    which shows 512Mb (prodn) and 256Mb, 128Mb planned.
    These parts DO have a 300mil 16-SOP package choice, which is easier to handle and prototype with than 6x8mm 24-TFBGA(5x5)
  • jmgjmg Posts: 15,140
    edited 2018-03-01 05:52
    ... and today I'll bump this with Cypress QuadSPI/DTR F-RAM offerings.

    https://www.businesswire.com/news/home/20180227005092/en/Cypress-Introduces-Nonvolatile-Memory-Family-Critical-Data
    http://www.cypress.com/products/excelon-fram

    54MHz using both edges, 108 MHz using one edge.
    Price is unlikely to be low, but this F-RAM does allow a softer mix of FLASH and RAM use in designs.
    - being a standard package, this allow easy swap of FLASH footprints.

    I see it has what sound like familiar reset commands, I think are already in the boot loader ?

    RSTEN 66H Reset Enable - Pre command to enable software reset
    RST 99H Software Reset - Command to initiate software reset

    tho Cypress are vague on if this can exit all chip modes.

    Addit: An email shows this as an eval board, looks like a standard CY8CKIT-062-BLE - I wonder when that starts fitting the F_RAM ?

    %7B7c42438a-1cf3-46b7-b9dd-80fe39ec5b90%7D_PSoC_Board_with_Excelon2-BOLD-960pixw.png
  • jmgjmg Posts: 15,140
    .. and another bump, for ST releasing STM32L4+ Discovery Kit, with OctaSPI memory included.

    https://www10.edacafe.com/nbc/articles/1/1575081/Macronix-8-bit-Flash-Memory-Complements-STMicroelectronics-STM32L4+-Discovery-Kit-Higher-Performing-Smart-Devices-Extended-Battery-Life

    Looks like XIP memory is going to be quite common when P2 hits full release.
  • cgraceycgracey Posts: 14,133
    Thanks for posting those, Jmg.
  • jmgjmg Posts: 15,140
    edited 2018-03-28 01:53
    cgracey wrote: »
    Thanks for posting those, Jmg.

    I've not found stock of these parts yet, but they seem to be both P2 boot (1b SPI ) and streamer ( 8b SPI) compatible.

    You may need to check the reset code, during boot ?

    They also have an optional defined bit-pattern that you can enable for read, that will allow some clock skew checking, as the P2 does not support DQS qualify.

    I also see a FastBOOT mode that looks interesting. A non-volatile config, can optionally set a just-send-data mode, immediately after reset.

    NV Bits 31 to 4 FBSA (FastBoot Start Address) 16 bytes boundary address for the start of boot code access.
    NV Bits 2 to 1 FBSD (FastBoot Start Delay Cycle) 00: 11 delay cycles 01: 15 delay cycles 10: 17 delay cycles 11: 21 delay cycles ( SPI is fixed 13 cycles)

    P2 could test for that, by simply clocking in for NOP out, 32 or 64 bits would show that mode alive, or not ?


    Reset itself looks rather slower than users might expect. Min pulse of 10us and fastest exit of 40us, slowest can be 100ms (!)

    Table 8. Reset Commands (SPI) Command  ( 3 x CS# ? )
    00 (hex)  NOP  (No Operation)
    66 (hex)  RSTEN (Reset Enable)
    99 (hex) RST (Reset Memory)
    
    Timing diagrams show only 2 CS# pairs of 66h,99h - NOP may just be in the reset group in the DOCs ?
    
    Table 12. Reset Commands (OPI) Command
    (byte)     NOP   (No Operation)   RSTEN (Reset Enable) RST (Reset Memory)
    1st byte   00 (hex)               66 (hex)             99 (hex)
    2nd byte   FF (hex)               99 (hex)             66 (hex)
    3rd byte   -                      -                    -
    
    I'm not sure if you can SW RESET when in Octal mode, without driving octal (8) pins ?

    Simplest way to manage P2 + OctaSPI, may be to include a small 25c MCU as Watchdog/Reset controller, driving each of P2 RST and MX25LM RST pins separately ?

    To most quickly confirm reset exit, this MCU might have to poll via something like RDID (9Fh) returns (C2, 85, 3A) but that operation conflicts with Fast Boot.

    Fast boot also mentions SPI/OPI/DOPI modes, but Config2 is Volatile bits defaults (RST?) of 00b => SPI, so it is not clear HOW you enable fastboot OPI/DOPI ?
    Undocumented bits somewhere ? - Still, P2 users would not do that.

    Maybe this needs a double-reset in that small MCU :
    * Pulse HWOctaRST
    * Repeat Emit 9Fh until <> 0xFFFFFF, check for C2H,85H,3AH, if match, reset P2
    * If not C2H,85H,3AH check for [BootTag >> (13-8)], if match Pulse HWOctaRST again, wait 40us, reset P2

Sign In or Register to comment.