EMC: Help on Row/Bank/Column vs Bank/Row/Column

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sun Oct 07 06:45:04 MST 2012
(I am using the LPC1778 208 LPFQ.)

What is the difference between the Row/Bank/Column and
Bank/Row/Column setting.

1) What is the practical difference (in the operation
   of the EMC)?

2) Why is there a choice?

3) Why would I choose one method over the other.
   Pros and Cons.

4) Is there any other background info on the EMC that
   relates or has any bearing on this?
   Or that this choice affects?

Any clarification from Dynamic RAM experts will be
gratefully received. -- Mike.

[lpcware]

Content originally posted in LPCWare by PhilYoung on Sat Oct 20 16:33:57 MST 2012
The potential benefits of BRC for displays are not as great as they appear since the CPU will generally need to access the memory to update the data displayed, this will inevitably cause a new bank to be accessed since it's highly unlikely that the CPU happens to be accessing the same row as the display, and very likely that the display will need to access a different row before the CPU completes all it's operations in the current row.
It may have some benefits if you are executing code from SDRAM also, but without a cache the execution performance from SDRAM will be quite poor anyway.
If you are using SDRAM for code execution then you should look carefully at function alignment to make sure that where possible functions to not cross a row boundary, particularly within loops as this will really impact performance.
Generally if you are not using it for display then RBC is probably better since it has a higher likelihood that on function return the calling function may still be in an open bank.
Again, if this is the case then careful analysis of call trees and function alignment can give performance improvements by making sure that frequently used call trees can exploit multiple banks.

[lpcware]

Content originally posted in LPCWare by DF9DQ on Mon Oct 08 03:03:39 MST 2012
Very good point! This common use case shows that RBC mode can be at a disadvantage, too. Actually, after enough coffee this morning, I now think it almost always has disadvantages :-)  The problem seems to be that you are out of luck as soon as your SDRAM access is no longer local. Code and LCD framebuffer (or any other data) in the same SDRAM device violate that rule.
It's easy to see where RBC is beneficial, but our typical applications may not qualify for it.

Now you could either use multiple smaller SDRAM devices (expensive), or distribute data over the different banks as you did (BRC mode). If you need data beyond the internal RAM, one could place that in another bank of its own.

Thanks again for your input. I hope I find the time to make some measurements to quantify the difference between the modes.

[lpcware]

Content originally posted in LPCWare by wmues on Sun Oct 07 11:00:46 MST 2012
I have a system where code is executed from SDRAM and the LCD display buffers are in SDRAM.

I placed the code in the lower part of the SDRAM, and the display buffers in the upper part. I use BRC, so there are different banks for code and display buffers. So the interleaved fetches of code and display data each are having an open bank of their own, minimizing the time for access.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sun Oct 07 10:17:23 MST 2012
Thank you Rolf; your reply was lucid, insightful, and informative. Just what a firmware guy needs in a hardware world.

And so quick too.

I saved a copy of the Philips document for later perusal.

Cheers, Mike

[lpcware]

Content originally posted in LPCWare by DF9DQ on Sun Oct 07 09:33:00 MST 2012
Hi Mike,

Here my personal view (before the experts move in...)

A simple rule is: Use BRC if you need partial array refresh on low-power SDRAM's, and use RBC in all other cases.
This is because RBC is faster than BRC, but doesn't allow partial array refresh.

BRC arranges the banks in logical address order. For a low-power four-bank 16 MiB device the first 4 MiB go to bank 0, and the last 4 MiB go to bank 3. If you concentrate all your valuable data on the lower quarter of the address range, you can keep the data with minimum power in self-refresh mode by telling the SDRAM to only refresh bank 0. Banks appear interleaved in the address space in RBC mode, so preserving only one bank in power-down mode wouldn't make sense in that mode.

Access to an SDRAM works by selecting a row for read/write access through the ACTIVE command. Selecting a row takes some clock cycles, and you want to avoid it as much as possible since it is just overhead. Each ACTIVE command opens a window of 2^columns SDRAM words in the selected bank. There is one such window per bank. If data access leaves that window, another ACTIVE command is required. In BRC mode the windows do not appear at consecutive addresses, and it is very unlikely that the CPU needs data from one of the open rows in another bank.

RBC mode interleaves the banks such that the open rows from all banks together form one big window four times the size. The access in this mode is faster, because it reduces the number of ACTIVE commands required. However, once you cross the window boundary, new rows need to be opened in all four banks. There's no such thing as a free lunch...

It should be noted that you will get that benefit only for a reasonable code and/or data locality. Pure random access will have the same probability of an "open row miss" (requiring an ACTIVE command) in both BRC and RBC modes. Practical cases will see a performance increase in RBC mode though.

No difference exists in the operation of the EMC. It's only a different initialization.

Regards,
Rolf

http://www.es.ele.tue.nl/premadona/files/akesson01.pdf