lpcware

LCD Bandwidth Calculator for the LPC18XX and LPC43XX

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by zp on Mon Sep 02 13:48:03 MST 2013
Dear NXP, your LCD Bandwidth Calculator http://lpcware.com/content/nxpfile/lcd-bandwidth-calculator-lpc18xx-and-lpc43xx is wrong.

Your calculus treats Data Rate as a value of (Screen_width x Screen_Height x RefreshRate) Mpixels/s. Then all other derivatives just rely on this.
Though Data Rate is calculated quite right you can use this value if your framebuffer is about the same every frame.

It is obvious that every horizontal line for the LCD is bigger than a screen width. The lines number is as well.
F.e. for a standard  640x480x60Hz  VGA the real horizontal pixel count is 800 and a full frame consists of 525 lines. This leads to the 25.2 Mpixel/s bandwidth. You shoud use this value instead of (640x480x60) = 18.432 Mpixel/s. The latter is just an average bandwidth  for a one second basis but the peak value of 25.2 Mpixel/s does matter. The difference is quite big - about 40%.

Of course, if you have a QVGA display or the static content in framebuffer, the SDRAM bandwidth does not get so big influence.
But in the single VGA mode and up LCD eats more than one third of the SDRAM bandwidth. F.e. for a fullscreen 3D rendering (i am working on)  you need to refresh background, Z-buffer etc every frame.  This leads to the situation when only two masters can do long-term work on an AHB bus. If more masters (SD, co-processor,GPDMA etc) are requesting the SDRAM, it does lead to more frequently LCD FIFO watermark level crossing and to round robin with a preference to LCD. Or even worse this means the exhausted FIFO. A tripple buffering is also impossible (more precicely - useless as it'll take more time than a double buffer scheme).

So it is worth to be mentioned that for a heavy graphics you must use the peak bandwith consumptions based on a LCD pixelcklock.

Outcomes