PSRAM interface, generic question, best practice? - Page 1
Forum section: electronics / general

author: betocool
author_rank: Regular Contributor
timestamp: June 08, 2025, 03:15:27 am
content: Hey all,For a project a colleague and I decided to try a PSRAM chip from Infineon plugged in directly to an FPGA. The chip offers 512 MBit memory and uses in total about 11 data lines. Commands, addresses, etc, are sent and received through these data lines.The beauty of these PSRAM chips is the amount of memory in a small package and the internal refresh options. The drawback is the interface, which is not the usual address + data + nWE/RE like for an SRAM chip. At this point the PSRAM in our project has been tested and a fit-for-purpose interface implemented. So far so good.My question regarding the interface is what is the best practice for interfacing with one of these chips, to make it flexible enough that one could read anything from 1 word to the whole memory, taking into account wait states, etc. Currently our applications writes data chunks of 32 words (or less when required), or multiple blocks of 32 words + remains (say, for example, 1000 words). The reading process is about the same, reading 32 words at a time or less, or blocks of 32 words + remains. The interface to the PSRAM controller is the start address, nr of bytes to read/write and read/write.I keep thinking there must be some sort of agreed upon interface, like AXI-4 or Wishbone that does the same? I didn't find many examples online about PSRAM interfacing, and Vivado does not offer a PSRAM interface in their IP catalogue. Fortunately the datasheet was pretty well written. And I haven't asked ChatGPT yet, so I thought I'd ask around here what people have done in the past.Looking forward to hearing your opinions.Cheers,Alberto

author: Someone
author_rank: Super Contributor
timestamp: June 08, 2025, 05:03:47 am
content: AXIn can map arbitrary linear address models, so it could have an adaptor made. But if the things which need to interact with the memory already use your own interface and do the job/work why add new complexity and cost?

author: iMo
author_rank: Super Contributor
timestamp: June 08, 2025, 06:22:50 am
content: Years back I created the similar device for myself having also 11lines and an8MB PSRAM(and xilinx CPLD interface). After issuing the initial address it used to use the auto-increment/auto-decrement address feature I implemented into the CPLD, so I did read/write the bytes with standard external sram MCU's interface (pic32MX at that time) reading/writing at the same MCU address. It was used as a swap disk for the retrobsd unix, so a sector was 512 bytes so the address setting overhead was rather small.Double check if your device has got such a feature.

author: asmi
author_rank: Super Contributor
timestamp: June 09, 2025, 05:05:11 pm
content: These devices are designed for streaming data in large bursts in order to amortize their very large access latency. Random access, while possible, is going to be very inefficient as unlike regular DDRx, these accesses can not be pipelined to hide access latency and increase data bus utilization (with DDRx you can send in a next read/write command while existing one is still being executed, so with smart request timings you can get very close to 100% data bus utilization). So if you absolutely need random access, you will be highly advised to have some sort of cache inside FPGA to increase efficiency and avoid random access to memory itself (because in case of cache miss you are going to read a full cache line as opposed to just single value requested).

author: betocool
author_rank: Regular Contributor
timestamp: June 10, 2025, 01:45:23 pm
content: Hey, thanks for the answers.I didn't know about the DDRx memory pipelined accesses, very interesting, although I haven't used one yet. You are correct that the overhead is large on the PSRAM itself, fortunately I mostly do burst reads/writes with a tail end at worst. I don't plan to do single reads or random access, so it works for our application very well. I was just thinking it'd be interesting to use such amount of memory for a soft core and some sort of bus, and also wanted to know what you guys were up to.Cheers,Alberto

author: asmi
author_rank: Super Contributor
timestamp: June 10, 2025, 03:17:25 pm
content: Quote from: betocool on June 10, 2025, 01:45:23 pmUnless your softcore has cache, it will likely issue requests for single reads/writes, so it's going to be the exact anti-pattern which I mentioned. So make sure you implement a cache, or two separate caches for instructions and data, so that accesses to memory would involve full cache lines as opposed to single words.