1
\$\begingroup\$

I am designing a microcontroller-based video system, and I am considering using SDRAM (~100MHz) for external frame buffer memory. (My microcontroller has plenty of I/O for the data and address busses and control lines, and can issue synchronous bus-wide signals at 100 MHz.)

My question is this: Is it possible to continuously stream data from one or more SDRAM chips using "back-to-back" full page burst reads? (A single full page burst read is 256 words, and I am using one word per pixel. In order to output an entire scanline without interruption, I would need a longer read to accommodate horizontal resolutions greater than 256 pixels.)

For example, consider the Alliance AS4C2M32S 2Mx32bit SDRAM. It has four internal banks of 512K words each. I read through the data sheet (more than once), but it is not clear if I can issue a new bank select just before the end of a full page burst read, followed by a new burst read command, so the output data stream will continue without interruption between the end of the first read to the beginning of the next. If I can chain four of these reads together I should be able to read out 1024 words (pixels) in one go; these will be fed directly to a video DAC.

I am aware of the complexity of implementing DRAM controllers, and I am also aware of other RAM types (such as dual-ported or VRAM) which are obsolete. This question is not about that. I also realize that many MCUs also come with built-in GPUs (such as on the Raspberry Pi platform); nevertheless, I intend to do this "from scratch" for personal reasons.

I simply want to know if anyone with low-level SDRAM experience knows if it is possible to seamlessly chain back-to-back full page burst reads for a continuous stream of data. (I hope to fit in refresh operations during blanking intervals...)

\$\endgroup\$
3
  • \$\begingroup\$ Yes it's possible with SDRAM (but DDR and DDR2 abolished page mode, making it harder). I ran an up-down counter to count up at the nominal refresh rate. Then, when a slack period happened (like your blanking interval) I counted down as I generated refreshes until it hit zero. (This was using Micron parts though) \$\endgroup\$
    – user16324
    Commented Dec 15, 2016 at 23:54
  • \$\begingroup\$ @BrianDrummond Thanks for the comment. Would you care to share your thoughts on my self-posted answer below? \$\endgroup\$ Commented Dec 16, 2016 at 0:13
  • \$\begingroup\$ Since when is the Raspberry Pi an "MCU"? The SoC that comes on a Raspberry Pi isn't even close to being considered a microcontroller. \$\endgroup\$
    – Chris_F
    Commented Sep 29, 2019 at 8:48

1 Answer 1

0
\$\begingroup\$

I just read through the datasheet (again), and I found the following paragraph (page 6), which I somehow missed before:

... The SDRAM has four internal banks on the same chip and shares part of the internal circuitry to reduce chip area; therefore it restricts the back-to-back activation of the two banks. tRRD(min.) specifies the minimum time required between activating different banks. ...

This would seem to mean the answer to my question is no. However, perhaps I can still achieve "continuous, uninterrupted streaming" by using two or more SDRAM chips on the same bus and interleaving reads.

\$\endgroup\$
3
  • \$\begingroup\$ Maybe some chips can do it and others can't, depending on whether or not the relevant internal circuitry is "shared" between banks or not. (speculation). It might even vary by manufacturer... \$\endgroup\$ Commented Jan 29, 2017 at 21:44
  • \$\begingroup\$ Interleaving burst reads among multiple chips seems like the most reliable approach, given the unknowns. \$\endgroup\$ Commented Jan 29, 2017 at 21:44
  • \$\begingroup\$ This seems wrong... tRRD needs to be observed between two banks activations, but an arbitrary numbers of banks can be active simultaneously. Isn't that the point of having different banks in the first place? See also: electronics.stackexchange.com/a/621660 \$\endgroup\$ Commented Aug 28, 2022 at 19:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.