I'm in a bit of a dilemma and I'm wondering if anybody here can help me.
For a display application in need to use a framebuffer which is at least 2Mbytes.This framebuffer is used to drive a 800×480 pixel TFT panel.
I wanted to use SRAM for this because I hear it is faster.
SRAM Part: IS61WV102416BLL
But i have now come across the following SDRAM IC:
SDRAM Part: IS42S16400J-7TLI
It seems to me that the SRAM has a acces time of 10ns while the SDRAM has a access time of 7ns. So, does this not mean the SDRAM is faster?
Thank you in advance!
Best Answer
SDRAM is transaction based; all accesses are burst based and therefore you will always have to use up a transaction period for all accesses. The part you link to can do a single read / write access (burst of one), but there are other overheads.
When I say transaction based, it means that there is more to a read or write than asserting that single command.
SDRAM accesses consist of opening a row, followed by a read or write command, then you need to wait for sufficient cycles to meed the CAS latency requirement; only then does the actual transaction take place. It is usually possible to continue to access a row without reopening it, but only until the refresh period has expired after which the row must be closed and then reopened.
Note that if you need to access truly random locations (in different rows) you will incur the row opening overhead for each and every row.
For video framebuffer applications, this will very likely be an overhead you will not want to have.
In addition, SDRAM will do refresh cycles to meet the overall refresh timing requirements, making accesses somewhat non-deterministic
The SRAM you link to has none of the transaction timing issues above; the total cycle time (for the actual data transaction) is 20 nsec (min), but in many applications the actual throughput of an apparently slower SRAM is higher than SDRAM.
You need to analyse the data throughput requirements, and how the data are stored in memory to see just what real throughput you will achieve,