Does PSRAM get outdated?

[soFPG]

I thought about using PSRAM as a video frame buffer for a FPGA / image sensor project I am working on, but for whatever reason there is a very minor selection of products one can choose from.
Needing several Megabytes of RAM doesn't help either.

What I was able to find are the LY68S3200SLT and the ESP-PSRAM64H.

Any ideas why there is such a limited selection? Should I rather go for more traditional SDRAM (unfortunately, packages are a lot bigger)?

[Benta]

Why PSRAM? It's an intermediate/temporary technology used for increasing density over SRAM until the next technology step.
It's basically DRAM with internal refresh and external SRAM interface.

But honestly, for a video system DDR DRAM would be much more appropriate. You have nice sequential access, which DDR likes.

[soFPG]

The main reason why I was considering PSRAM is due to its small SOIC-8 package.
SDRAM or DDR-SDRAM usually has a high number of pins and therefore a larger package.

[Benta]

In that case you're looking in the wrong place. The operative word is not PSRAM.

Search for SPI RAM instead.

[soFPG]

SPI RAM is mostly going to be SRAM - which is expensive considering several Megabytes.

I don't see how SPI SDRAM would work out if not in the form of PSRAM.

[Benta]

SPI RAM is just that. Whether it's based on SRAM or PSRAM doesn't change the functionality. And yes, SRAM costs more that PSRAM due to larger die size. But the number of available parts is much larger.
You decide what you need.

and SDRAM is something completely different.

[Berni]

The whole PSRAM thing is just a dirty hack of placing some adapter circuitry in front of a DRAM memory to make it look like it is SRAM.

The adapter circuitry can't magically work around the latency and refresh limitations of DRAM. So the timings have to be set for worst case scenarios. This gives them the performance of pretty old slow SRAM when used purely like SRAM.

The fact that it is SPI might be useful when using it with a MCU, but on a FPGA that SPI is just going to be a nuisance. If you need a large amount of high performance RAM use a SDRAM chip. There are ready made controllers for those on all FPGAs, they don't need funky length matched traces to work (like DDR does), they are dirt cheep, they multiplex the data and address lines to reduce pin count (versus oldschool parallel SRAM) and will easily run at >100MHz giving you Gigabits/s of memory bandwith. If you need the chip to be small you can buy them in a 0.8mm pitch BGA package that is similar in size to that wide SOIC8 while easy enough to handsolder with hot air, requires no special tiny traces or tiny vias to layout so the PCB is cheep...etc

[Siwastaja]

I understand the desire for small pin number, slow SPI interface, for small microcontrollers, but for an FPGA project doing image processing, just use bog standard SDRAM: large memories available, with better performance, and at lower cost. Small packages exist, you just need to bite the bullet and hot air solder tiny packages. It's not too hard.

I understand there are cases you want a hardware control layer handling the SDRAM addressing and refreshing, emulating SRAM, but on FPGA, this is trivial to do yourself.

[T3sl4co1l]

I'm rather more curious how you figured SPI has enough bandwidth to function as a video buffer?

Tim

[soFPG]

The time I looked at some PSRAM datasheets I noted that SPI would run at ~133MHz (often QSPI capable).
So bandwith shouldn't be a problem (probably why espressif's ESP32 uses SPI for external flash as well as for external PSRAM).

I am not talking about 4k video but rather about something like 640 x 480.

[ace1903]

I looked for easy PCB design and small high throughput interface and found this:
https://www.cypress.com/file/498621/download
Looks like DDR memory but with the only dozen high-speed lines.
Never went to make actual design with it. QSPI sounds nice but is not standardized well and accepted among silicon vendors.

PSRAM was a thing 2006 and quickly forgotten. Beside espressif no one else uses actively.
But when memory prices went up, some Chinese companies used old technologies and foundries to fill the marked gap.

[Benta]

The time I looked at some PSRAM datasheets I noted that SPI would run at ~133MHz (often QSPI capable).
So bandwith shouldn't be a problem (probably why espressif's ESP32 uses SPI for external flash as well as for external PSRAM).

I am not talking about 4k video but rather about something like 640 x 480.

Dunno how much bandwidth you need. QSPI would give you around 20 Mbytes/s maximum (and that's probably even too optimistic).

[BrianHG]

You've got a wide selection.  Be careful as some like the Hyperbus variety have half the access time making them better.
Like others have said, unless you are trying to save IO count, a DDR2/3 ram would just be easier.

Also, everything is going BGA as seen by the selection here:

https://www.digikey.com/products/en/integrated-circuits-ics/memory/774?FV=961%7C390622%2C-8%7C774&quantity=0&ColumnSort=1000011&page=1&stock=1&nstock=1&k=psram&pageSize=100&pkeyword=psram

Though, the most common 48-FBGA (6x7) 1mm BGA is easy to mount as it is so small.
The 44-TSOP is available, but I do not know for how long.

[soFPG]

Dunno how much bandwidth you need. QSPI would give you around 20 Mbytes/s maximum (and that's probably even too optimistic).

Dunno how you calculated that value. 133MHz * 4 data lanes (QSPI) = 66Mbyte/s

Even QSPI Flash is able to transfer 50 Mbyte/s: https://www.winbond.com/resource-files/w25q128fv%20rev.l%2008242015.pdf

Like others have said, unless you are trying to save IO count, a DDR2/3 ram would just be easier.

I don't think I am going to make a DDR2 or even DDR3 design any time soon. I'll stick with SDRAM for now, thank you.

[Scrts]

You can also have a look into Cypress HyperRam, which is 24 balls BGA, 5x5mm package. Works in Octal SPI mode as well:
https://www.cypress.com/file/498616/download

[Benta]

Dunno how much bandwidth you need. QSPI would give you around 20 Mbytes/s maximum (and that's probably even too optimistic).

Dunno how you calculated that value. 133MHz * 4 data lanes (QSPI) = 66Mbyte/s

That's correct for raw data rate. However SPI also includes overhead. For a super-optimized read-only or write-only QSPI setup, around 50 Mbytes/s is peak transfer rate. You'll never get there in practice.
Second, we're talking about write AND read (yes, I know SPI is able to do this simultaneously, but QSPI is not). Now we're down at 25 Mbytes/s peak. Add lane direction change with associated command overhead, well... 20 Mbytes/s peak is reasonable, even optimistic

But using SDR SDRAM is a good idea and easy to implement in an FPGA.

[T3sl4co1l]

What are those protocols usually, something like command followed by N data?  So, there'll be configuration registers, an address register, commands to mutate them, and commands to read/write bursts of data?

So a random R/W, is a small fraction of total throughput: if you're transmitting 3 bytes of address for 1 byte of data (R/W) that's 1/4 raw, but also the overhead of two command bytes, so 1/6th or about 8MB/s!

If you were doing a display that has exclusive RAM access during scan, and maybe allows one other access during horizontal retrace and some more during vertical (or if this is for an LCD panel, then not necessarily retrace, but the corresponding "porch" timings typical of unbuffered display controllers), that might work; especially if data can be streamed out continuously without being restricted to fixed length burst modes.

I suppose performance would be comparable to old school EGA or VGA, where the display controller takes priority and refuses bus access (forcing WAIT states until available).  The redraw time is usually abysmal.

But yeah, by far the better solution is to just get some SD or DDR RAM that the FPGA is happy with.  Could even start with a dev board that comes with both; they're very affordable these days.

AFAIK, the RAM controller is just a drop-in IP block, and resolves all the timing and bus access you need.  Maybe add some buffering for the priority output stream (display read), since it's a hard real-time output.  Could even control refresh cycles, since you probably don't need to waste time refreshing currently-unused RAM?  Or, you can use it for everything else too; if this is for a vintage computer add-on, for example, you could add a direct RAM window (as EMS or etc.) and toss a few megs at the CPU for no cost.

Tim

[TimCambridge]

AFAIK the ESP RAM is a badged version of the Lyontek part. It's DRAM based and pretty easy to use but obviously not as straightforward as the pure SRAM QSPI parts.

You can also have a look into Cypress HyperRam, which is 24 balls BGA, 5x5mm package. Works in Octal SPI mode as well:
https://www.cypress.com/file/498616/download

HyperRAM (A.K.A. Octo-SPI) is much higher bandwidth if you have a streaming application - 200MHz DDR if you get the timing right HyperRAM on an FPGA is somewhat tricky, much easier if you have some block RAM FIFOs to play with and/or if you don't need to run the read side at full speed.

The main area of difficulty with HyperRAM is handling the read strobe, just like DQS on a DRAM. The ST Microprocessors that implement this interface have dedicated logic to insert the correct delays, I expect other micros do the same. The next generation of parts, supposedly available at the end of 2020, will have DCARS (DDR Center-Aligned Read Strobes) which will make it easier for bare-bones FPGA implementations.