Types of RAM for the P2
__red__
Posts: 470
in Propeller 2
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
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
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. : ]
But you need a lot of pins. You can use some Glue Logic and do paging to cut down on pin use.
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).
What if these were pre-made and ready to go with P2-Eval?
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
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.
Static ram is the simplest, dynamic ram the most complex, and pseudo-static slightly simpler than dynamic.
All 3 types of memory are fast enough that the P2 will likely be the limiting factor in read speed.
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
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.
Seconded!
J
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)
It looks like a good balance between pin count, speed and complexity of interface.
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.
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*
*hahah*
I found this:
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.