Question about the speed of SPI RAM

How big does the SRAM need to be ?

If you only need a modest size, here's a couple of reasonably priced parts:

Microchip 23K640 - 64Kb, 20MHz SPI Microchip 23K256 - 256Kb, 20MHz SPI

SPI RAM is going to truly suck if it is really used as random-access memory. If randomly addressing word variables, you need to send two or more bytes of address for each word retrieved. With 20MHz SPI clock speed, each address or data byte takes 200nSec. Retrieving a randomly addressed word takes 4 byte transfers, or 800nSec. This is really going to slow down a 100mHz processor.

Mark Borgerson

With these numbers, I don't expect the processor will signifficantly slow down. What's a mere 800ns on a 10s instruction cycle (assuming one cycle/clock). ;-)

Random access does not imply that it is being used as primary storage for instructions and/or data. As a temporary dumping ground for data that may be needed as some point later even slow memory may prove perfectly adequate, especially if SPI is done in hardware.

s:

rts:

Good point. However, I believe the additional memory is likely to be used only occasionally and temporarily, to swap data back and forth to the main memory. The firmware is likely to be executed at the main memory only. So maybe the performance is not too bad.

y by mail)

Could you please let me know where the 10s instruction cycle come from? Is it 10ns?

Right. It is my user case.

Has anybody know any other way to connect the RAM to the processor with only a few IO pins, and run faster than SPI?

tHANKS.

It is a literal interpetation of a quoted speed of 100mHz: i.e.

SPI has very low overhead for a given serial bit rate, I would guess no.

The real-world numbers are a lot worse than that. First, unless I am making a silly mistake, an 8-bit byte transfer will take 400 ns at 20 MHz spi clock. Then to access data on the second chip you mentioned above, you are going to need at least one "command" byte and three address bytes, giving four transfers before the data itself. You also have overhead for things like the chip select and setup. So in practice you are looking at around 2 us per transaction, plus 400 ns per byte transferred.

The key to making this efficient is to overlap the transfers with other work. If possible, use DMA to handle the transfers. So when you want to read data, set the read transfer in action as early as possible, and the DMA will handle the data while your processor does something else. Keep your data in the SRAM in blocks (typically an array of structs) so that you can do your transfers using only a few transactions.

For example, if your program has a sampling function that runs at 1 KHz and collects data, then needs to write it out to SRAM, you can set that writeout in action at the end of the sampling function. Your processor can do other things while the DMA handles the transaction, and it doesn't matter much how long that takes.

Good Catch! those dang millis and megas just keep switching places on my keyboard!

Mark Borgerson

OK. I've used SPI NVRAM in similar situations as buffer memory between two processors. If you use SPI memory in situations where you can transfer larger blocks of data back and forth between normal RAM it is a lot more useful.

Mark Borgerson

Your choices would include change any existing i2c memory to Ramtron FRAM, as that can work as SRAM at moderate rates, and also as EEPROM

SPI is usually the fastest serial link, to some tens of MHz, but there are QuadSPI devices (in Flash mainly; I think Cypress were talking of NvSRAM in QuadSPI soon ?)

Of course, Quad SPI needs more pins (4 data lines), and a processor with a quad capable peripheral.