Using Frame buffer in SDram

[lpcware]

Content originally posted in LPCWare by askar on Mon May 05 04:54:00 MST 2014
Hi,

I want to know,  if we put frame buffer in sdram and meanwhile we use sdram for seconds, for example
moving large blocks of data from one location to another, would this affect the performance of LCD controller?
or we will have a steady display on LCD?

Best Regards,

[lpcware]

Content originally posted in LPCWare by mc on Fri May 09 11:21:00 MST 2014
Hi asker,
Normally yes, there should not be any problem. Please check the bandwidth using BW calculator as well. For example, if you use 24bit per pixel,pixel depth with a LCD of 800x460 pixel resolution,there will be overwhelming traffic from/to SDRAM.

[lpcware]

Content originally posted in LPCWare by askar on Mon May 05 21:11:44 MST 2014

Hi mc,

Thank you for your fine description,
so I will have no problem in normal operation when short burst size of SDram will be used.

Best regards.

[lpcware]

Content originally posted in LPCWare by mc on Mon May 05 07:02:07 MST 2014
Hi askar,
The LCD controller is one of the Bus master in LPC4350 and has the highest priority to access EMC port.
If there are  bus masters with same priority,  LPC4350 uses round Robin bus arbitration method. In this controller we can not prioritize bus master’s access to a slave port.
Please see below the fix  priority level from high to low.
1.LCD controller                               ->Highest
2.CPU S-bus
3.CPU I/D-bus
4.Other bus masters                     ->Lowest
Therefore, if LCD controller and other bus request simultaneous access, LCD controller will be granted access. Although the LCD controller has highest priority, however it can still be stalled if another lower priority access has started that has a long burst length .
To avoid starvation, short  burst size should be used to tune overall performance.For example if  you are using GPDMA, an another bus master on this multilayer bus to access EMC port, I would like to have a smaller bust size to avoid any starvation.

To avoid data underflow  the LCD controller  also has a large FIFO  (16x64 bit). So the  LCD FIFO needs to buffer enough data to keep the LCD refreshed - smoothly - even when the system is under load. In some cases, system events can occur that cause the LCD FIFO fill to be delayed.
For example, the CPU might be doing a burst read from SDRAM (memcpy, or maybe an LDM operation with a stack pop), but this may get stalled due to a SDRAM refresh cycle. If multiple stalls like this happen, it can cause delays to the LCD refresh cycle and the LCD FIFO will eventually underflow and you may get a display glitch/tear. In general if you are using 16 bits SDRAM data interface with multiple bus masters, there are more chances of tearing than with 32 bit SDRAM data interface.  Please find below link which has bandwidth calculator

http://www.lpcware.com/content/nxpfile/lcd-bandwidth-calculator-lpc18xx-and-lpc43xx

This calculator is a good tool to check loading on the EMC bus