Electronics > Projects, Designs, and Technical Stuff

Does PSRAM get outdated?

<< < (4/4)

Benta:

--- Quote from: soFPG on July 20, 2020, 03:34:01 pm ---
--- Quote ---Dunno how much bandwidth you need. QSPI would give you around 20 Mbytes/s maximum (and that's probably even too optimistic).
--- End quote ---
Dunno how you calculated that value. 133MHz * 4 data lanes (QSPI) = 66Mbyte/s

--- End quote ---

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. ;D

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.


--- Quote from: Scrts on July 20, 2020, 04:41:39 pm ---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

--- End quote ---

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.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod