Using Quad-SPI PSRAM with a STM32-H7 -- is that possible, and wise, performance-wise?

[FBert.1]

Hello,

I am in the process of designing a product which is based on the STM32-H7 and requires more RAM, somewhere in the 2-digit MB range (8 or 16 MB should do).

As I understand, I have several options:

• Using SD-RAM with the Flexible Memory Controller (FMC)
• Using some other form, e.g. PSRAM with the FMC
• Using the Quad-SPI interface with a QSPI-PSRAM component, e.g. this https://www.espressif.com/sites/default/files/documentation/esp-psram64_esp-psram64h_datasheet_en.pdf

The FMC options -- regardless of whether PSRAM or via the SD-RAM banks, swallows a considerable amount of pins: I think I'm around 20+ pins with 4 SD-RAM banks and 11 address bits, with 8 bit data. It gets a lot worse if I opt for 16 or 32 bit data.

The Quad-SPI memory would be considerably easier to integrate, at the expense of two disadvantages:

• Availablility
• Performance

As far as performance is concerned, I have the STM applicatio note AN4891 (see https://www.st.com/resource/en/application_note/dm00306681-stm32h72x-stm32h73x-and-singlecore-stm32h74x75x-system-architecture-and-performance-stmicroelectronics.pdf ), which essentially tells me (tables 18 and 19) that 8 bit performance of SDRAM cost me somewhere around 30-50% worse performance. At the same time, using Quad-SPI FLASH costs me roughly around 50-90% performance (e.g. table 13), as in: twice as slow as the reference memory configuration from the AN4891 benchmark application.

So the tradeoff with regards to performance, if the number of pins is of concern, seems to be: lose some performance (say, around 30%, give or take?) in exchange for a lot of pins :)

Now to my question(s):

Is my assesment correct? If I buy a QSPI-PSRAM module that fits my needs, is that really all I lose? A factor of <= 2 in performance? Or are there more subtle implications that I'm missing here? (Why isn't everybody using QSPI-RAM then?)

Cheers,

F.

[Tesla DeLorean]

My advice would be make it work on a NUCLEO-144 first, the headaches here are in the implementation/details. It will save a lot of board bring-up time later, and save spinning boards. Plus you can benchmark your own use case.

The cache and write-back mechanisms can mask a lot of slowness on the CM7's. SDRAM was pretty slow on the F4's code execution was 6x slower (no cache, no ART)

QSPI-FLASH on the H7 is pretty aggressive, dual bank interleaved (10-pin ?), should be able to sustain close to 100 MBps on large block transient stuff.

QSPI-PSRAM, that's a bit more of an unknown, I think only some of the newer H7 designs support that, and I'd read the errata very carefully.

I'd be more comfortable with 16-bit SDRAM (or 32-bit for high bandwidth transient buffers), and eat the IC/PCB complexities.

Do you need to use LQFP? Do you need small size board?

[Andreas Bolsch]

The Quad-SPI-interface does allow only memory-mapped reads, not writes. Hence writes must be done via indirect write, that's getting somewhat complicated and slow.

For RAM only the Octo-SPI-interface (in the newest H7 variants) seems to be a feasible choice. But as already noted, the errata sheets are quite long, so check carefully and on real hardware whether this works for you *before* taking any decision.

[FBert.1]

"The Quad-SPI-interface does allow only memory-mapped reads, not writes."

Ah, so that's the information I've been overlooking :)

I need "regular" RAM access, so it seems like I'm stuck with the FMC for my application, for now. (Or Octo-SPI with the newer chips, as you guys suggested.)

Thanks & Cheers,

F.

[Alex - APMemory]

Hi,

Just adding few comment: as you mentionned QSPI & OPI PSRAM are saving a lot of pin (QSPI SDR 6pins, QSPI DDR 7pins, OPI 11 pins, HPI 20pins) compared to ADMUX or SDRAM, but non only. They are also providing a wide range of density (from 16Mb up to 512Mb), of bandwitht (72MB/s up to 800MB/s), of package (from basic SOP8 up to BGA or WLCSP), and easy and competitive to source, just providing 2 links to APMemory IOT RAM fyi:

https://www2.mouser.com/c/semiconductors/memory-ics/dram/?m=AP%20Memory%20Technology

https://www.rutronik24.com/pgm/apmemory/dram/icdram/

Hopefully, you might find most optimized memory solution for your application when using latest MCU

Regards

Alex

[Tesla DeLorean]

Do you have any worked solutions for the STM32 parts, perhaps enumerating what's supported by what, and small test boards that could plug into the NUCLEO-144 boards demonstrating usability/viability?

[Alex - APMemory]

IoT RAM devices are supported on STM32L4P5, L5, H7A/B, H72x/3x, U5..., all MCU having Octa memory controller. Some may have limitation for specific configuration, like mentionned above QSPI SDR memory wrapped write is not supported by H7A/B and H2x/3x. In this case QSPI DDR might be an alternative as well as OPI.

The Nucleo board usally doesn't have dedicated slot for RAM, but we can find it on Disco or Eval board, which have BGA24 footprint (There are also PMOD daughter board option for some board). We have tested some config in our Lab using disco, and STM some other (for example 16MB OPI APS12808L-3OBM reference in section 7.9 of UM : https://www.st.com/resource/en/user_manual/dm00682073-discovery-kit-with-stm32h735ig-mcu-stmicroelectronics.pdf)

Regards

Alex