Types of RAM for the P2

Greetings(!)

I'm not as au fait with different types of RAM as I need to be, but with the imminent arrival of the P2 test boards I'm going to need some external storage to work with.

Obviously, since there are seemingly a thousand types I will assume that's because there's a whole bunch of compromises to be made.

Since I'm just prototyping here let's say:
i. Ease of implementation (ie, hopefully someone else has already written the hardware driver / will be written really soon).
ii. Speed, less important.
iii. Size, 4-16M(bytes)

My target application is a network-attached MMU if that helps any.

Something I can get arrow.com to overnight to me and won't be too hard to interface to the P2 development board.

Suggestions?

Thanks,



Red

Comments

  • 18 Comments sorted by Date Added Votes
  • Ym2413aYm2413a Posts: 628
    edited December 3 Vote Up0Vote Down
    I think a big question is how many pins you want to give up and what kind of package you can work with.
    I don't know about you, but I have a hard time soldering in those really small pin packages and that always is my limiting factor!

    I mean it shouldn't be too hard to find something that fits those three requirements. : ]
  • Also the easiest to work with are Static SRAMs.

    But you need a lot of pins. You can use some Glue Logic and do paging to cut down on pin use.
  • I really don't want to do BGA. I'd rather avoid QFN too if I can.

    With 64 pins I'm willing to give up 16, or even 32 pins for memory access if it has to be a power of two.

    (but like I said, for development speed is less important).

  • HyperRam and HyperFlash, from vendors like Cypress and ISSI, look like a really good match for P2. They even top out around 333 MB/sec which is a great match for P2 overclocking

    What if these were pre-made and ready to go with P2-Eval?
  • jmgjmg Posts: 12,618
    edited December 3 Vote Up0Vote Down
    __red__ wrote: »
    I'm not as au fait with different types of RAM as I need to be, but with the imminent arrival of the P2 test boards I'm going to need some external storage to work with.

    Since I'm just prototyping here let's say:
    i. Ease of implementation (ie, hopefully someone else has already written the hardware driver / will be written really soon).
    ii. Speed, less important.
    iii. Size, 4-16M(bytes)

    No mention of width, and some bandwidth indication would help ?

    There are the usual-suspects of SDRAM and SRAM, in higher pin count packages.
    eg Digikey stock SDRAM like W9812G6KH-6, W9825G6KH-6 etc

    ISSI are a good place to start, for SDRAM and Async SRAM

    http://www.issi.com/US/product-asynchronous-sram.shtml#jump5


    ISSI now do 45MHz QuadSPI SRAM, up to 2 & 4MBit, and if you need more BW and can tolerate more used pins, they also have Latched SRAM & Muxed SRAM in 4Mb
    They also have hyperRAM, BGA but I think someone here has done a breakout.

    Various companies also offer SDRAM in 8 pins, to 64Mb - these are low cost, and would make useful frame buffers.
    eg https://www.electrodragon.com/product/2pcs-ipus-ips6404-iot-ram/

    These are similar to hyperRAM, in that they need refresh time slot handling, but are easier to handle.
    Support code would be quite similar, differences are at very lowest level where hyperRAM is DDR

    Addit:
    There ie also OctaRAM, claims M/P, but not easy to find... (24B BGA 6x8mm)
    http://www.jeju-semi.com/Products/OctaRAM


  • __red__ wrote: »
    Greetings(!)

    I'm not as au fait with different types of RAM as I need to be, but with the imminent arrival of the P2 test boards I'm going to need some external storage to work with.
    ..................
    Basically 3 categories of ram to choose from.
    SRAM - Static, easiest to interface, fast, highest cost/MB
    PSRAM - Psedostatic, more difficult to interface, somewhat slower, lower cost/MB
    DRAM - Dynamic (complex interface, needs refreshing), lowest cost/MB

    To me, the extra cost of static ram for 4-16MB is well worth paying for the hardware and software simplicity it makes possible.
    i. Ease of implementation (ie, hopefully someone else has already written the hardware driver / will be written really soon).
    Static ram is the simplest, dynamic ram the most complex, and pseudo-static slightly simpler than dynamic.
    ii. Speed, less important.
    All 3 types of memory are fast enough that the P2 will likely be the limiting factor in read speed.
    iii. Size, 4-16M(bytes)
    There are 64Mbit sram chips available as 4Mx16bits or 8Mx8bits in BGA and 48pin TSOP
    https://www.mouser.ca/Semiconductors/Memory-ICs/SRAM/_/N-4bzptZ1yzvvqx?P=1z0vzw7
    My target application is a network-attached MMU if that helps any.

    Something I can get arrow.com to overnight to me and won't be too hard to interface to the P2 development board.

    Suggestions?

    Thanks,



    Red

    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • After posting my previous suggestion and then reading Tubular and jmg's suggestions I have to retract that suggestion and agree that hyperRAM is the way to go. Much simpler than trying to interface static or dynamic memories.

    Having a generic hyper-bus driver for the P2 that could be used for memory as well as other possible I/O applications would be a bonus.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • I want a HyperRam addon board.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • thejthej Posts: 173
    edited December 3 Vote Up0Vote Down
    potatohead wrote: »
    I want a HyperRam addon board.

    Seconded!

    J
  • Tubular wrote: »
    HyperRam and HyperFlash, from vendors like Cypress and ISSI, look like a really good match for P2. They even top out around 333 MB/sec which is a great match for P2 overclocking

    What if these were pre-made and ready to go with P2-Eval?

    A breakout board with Eval would be great ! They should really have gone onto the main board, HyperRAM has been known about for a long time now...

    The 333MHz is only for 1.8V and that includes DDR, so the clock is 166Mhz.
    The 3v3 spec is 100MHz clk, for 200 MB/s transfer, which is a modest overclock on current targets. Chip seems to think 250M is a ~consumer-grade possible P2 spec.

    Looking at the data, HyperRAM has a RWDS qualify signal, but that is DDR and P2 has no support for DDR clk in, on streamer.
    ISSI specs 1 ~ 5.5ns as valid data delays, so P2 tsu.th may determine the possible clock speeds.

    RWDS is still useful for refresh checking, and it can be checked for correct clock counts eg if streamer captures 9 bits, that can include RWDS and checked for when valid data appears, for debug.
    A sweep using the PLL, might be able to resolve that actual RWDS edge, which data specs with 0.8ns of data change (nominally identical)
  • After reviewing the HyperRAM datasheet.
    It looks like a good balance between pin count, speed and complexity of interface.
  • JRetSapDoogJRetSapDoog Posts: 786
    edited December 4 Vote Up0Vote Down
    jmg wrote: »
    Various companies also offer SDRAM in 8 pins, to 64Mb - these are low cost, and would make useful frame buffers.
    eg https://www.electrodragon.com/product/2pcs-ipus-ips6404-iot-ram/

    These are similar to hyperRAM, in that they need refresh time slot handling, but are easier to handle. Support code would be quite similar, differences are at very lowest level where hyperRAM is DDR
    I'm curious about the "but are easier to handle" part. I wonder how so. Is it because it uses the familiar SPI/QPI interfacing? I also wonder about the downsides, if any. Data transfer rate? Availability? Not a standard part? I mean, if it's relatively easier to use and uses fewer pins than HyperRAM, then I wonder why we're gravitating towards HyperRAM. I'm obviously missing something. I'm okay with HyperRAM using 11 pins and it's available and seems to be becoming entrenched. I'm just curious about this possible alternative. As for speed, anything that can be used as a frame buffer seems pretty good.
  • jmgjmg Posts: 12,618
    edited December 4 Vote Up0Vote Down
    I'm curious about the "but are easier to handle" part. I wonder how so. Is it because it uses the familiar SPI/QPI interfacing? I also wonder about the downsides, if any. Data transfer rate? Availability? Not a standard part? I mean, if it's relatively easier to use and uses fewer pins than HyperRAM, then I wonder why we're gravitating towards HyperRAM. I'm obviously missing something. I'm okay with HyperRAM using 11 pins and it's available and seems to be becoming entrenched. I'm just curious about this possible alternative. As for speed, anything that can be used as a frame buffer seems pretty good.


    Sorry, I was a bit brief.
    Easier to handle meant mainly physically, as it is a SO8 vs BGA24
    However, in raw performance terms, the HyperRAM/OctaRAM wins, with data moving on each edge, and 8 bits wide. Thus anyone chasing bandwidth, who is comfortable with BGA, will likely select HyperRAM.

    The specs of all these parts around refresh are quite poor. Usually, there is some ballpark like 32ms or 64ms for the refresh frame rate, and you can work backwards from the 4us tCSM * 8192 pages to get 32ms
    - but they do not say if you average that 4us, is that ok ? Nor do they mention if you hold CS=H, what the self-refresh rate is then ) ie how fast does the self-refresh clock run, internally) ?
    They just spec tCSHI > 10ns (some parts > 18ns).
    Also unclear is if 8192 CS cycles are needed within 32ms, (as would be the case, if CS incremented the refresh counter), but they claim self-refresh, which infers some internal counter.

  • Thanks for that great explanation! Your original comment was fine; I just lacked the background to read between the lines. But it was very kind of you to expand things for me. In another thread, I'm thrilled to see HyperRAM being added (as an option) to the P2D2. Yes, the SO8 from your link looks very easy to handle, but it seems best to "bite the bullet" in terms of handling complexity in order to gain the throughput advantage of BGA-based HyperRAM (or OctaRAM, assuming it's confined to BGA packages). Again, thanks for the explanation, as well as those other details. By the way, your earlier post mentioning "tsu.th" had me googling, too, but I think I got the basic idea about the window involved, even if I didn't fully work out the abbreviations (perhaps setup and hold times). Obviously, you're not talking to a PHOSITA = Person Having Ordinary Skill In The Art (I'm more of a PHOISITA = Person Having Ordinary Ignorance In The Art).
  • I'm leaning to HyperRAM mostly because of the balance between pin count and the 8bit bus width.

    The little serial RAMs are cool, but at the same clock speed will be much slower in terms of getting data in and out of them one bit at a time.

    The other option "which I'm more familiar with" is using good old parallel SRAMs. But you're looking at a pin count of 40 to 50.
    You can use some glue logic like latches to lock the upper address lines and use a page switching model to cut down on pins.

    But HyperRAM seems to eliminate that at the cost of some additional code to manage the HyperBus interface.
    Now only if the came in a 24pin DIP package that would be wonderful! *lol*
  • QSPI seems reasonably simple and I guess you can always parallel up the QSPI RAMs to get byte wide access too. Some parts are rated at 133MHz at 3V, not as fast as HyperRAM but not a total slouch either. Using 10 pins @ 133MHz is 133MB/s raw transfer rate which could support some video resolutions, though only one pin more for HyperRAM seems to buy a lot more performance. Need to learn more about the refresh limitations of PSRAM.
  • Ym2413a wrote: »
    Now only if the came in a 24pin DIP package that would be wonderful! *lol*
    Buying chips, soldering them onto DIP adapter PCBs and selling the result sounds like a good business idea. Someone get on that!
  • Ym2413aYm2413a Posts: 628
    edited December 4 Vote Up0Vote Down
    Wuerfel_21 wrote: »
    Buying chips, soldering them onto DIP adapter PCBs and selling the result sounds like a good business idea. Someone get on that!

    *hahah*
    I found this:

    IPC0171_0.JPG

    I think maybe some solder paste and a heat gun might do the trick?
    If not. could always get out the jewellers eye and attempt a dead bug style hack.
Sign In or Register to comment.