LCD Bandwidth Calculator for the LPC18XX and LPC43XX

lpcware · ‎06-15-2016

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.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by zp on Thu Sep 05 08:54:37 MST 2013
Anybody here?
I was wrong in my previous post speaking your calculation is right for the single frame.
Of course, from the view of pure math it certainly not because you wrongly assumed the datarate is a constant value.

One may ask why it is so important not to use the "average temperature in a hospital"?.
The answer is : the "averaged pixelclock" does not give the right base for a proper LCD FIFO exhaustion calculation.

To dig it deeper lets count the maximal time the LCD FIFO can withstand without to be pumping up with the new pixels.
The FIFO depth is 16x64bit (x 2 for a single LCD, I wonder why NXP uses 64-bit units while AHB in their LPC43xxx is 32bit? I can understand Freescale with their AXI bus where the display block got 64-bit bus and FIFO measured in 64-bit units. Q: Why the LPC43xx LCD FIFO is measured in 64 bits?)

But from the UM1053 p.802 is not clear does two composed FIFO will work as a two AHB masters. In practice the SDRAM memory transfer speed is slowing down unproportionally when the screen resolution is going up, showing that the LCD master is getting the preference on the bus.

The FIFO capacity is 256 bytes, DMA request is asserted when at least 4x64 (Q : or 4x32?) bits are eaten, so there is only 224 bytes. For the 16bpp mode it does mean 112 pixels. We have 112 * (1/25MHz) = about 4.5 microseconds to refill the FIFO.(Q: What kind of burst the AHB arbiter can grant to LCD controller? Q: Can the AHB arbiter in your AHB realization reject granted to other master access in favour of LCD controller?).

If the AHB arbiter honestly allocates the bus bandwith (based on a pure round robin algorithm) and assume the every bus grant is equal to the SDRAM burst, the time consumption is at least (i.e. 4 * 15 x (1/112Mhz) = 0.536 microseconds per master.

So 4.5 / 0.536 gives us that only 8 masters can somehow work on AHB bus.
Your calculator insists their number is at least 11. Though 8 masters seems to be quite acceptable.

But in case of 1024x768x16 bpp mode and 65 MHz pixelclock there are only 1.72 microseconds to refill FIFO and only three masters are allowed. Meaning that any AHB master activity (not even required access to the SDRAM) leads to LCD FIFO exhaustion. This is fully confirmed by practice. But your calculator allows at least four masters.

As to 3D rendering I can't say I'm novice in this area but my 3D experience is quite outdated. May be I'll create the new topic for this.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by zp on Tue Sep 03 08:26:30 MST 2013
Hi, Wouter!
I do not mix anything.

Let's go.

Configuration:
We'll continue with a standard VGA mode 640x480x60 Hz and 16bpp.
SDRAM & bus are 32-bit, EMC clock 114MHz, Trp = Trcd = CAS = 2;

Consider a time basis is not 1 second but just a single frame.
Your calculation looks like:

Data Rate in Mpixels/s = 640x480x60 = 18.432
Data Rate in Mbursts/s = 18.432 / 8 = 2.304

Bandwidth needed by LCD = ((15 * 2.304) / 114 ) * 100% = 30.3%
Fine.

But too far from truth if the time basis is more than one frame because it shows just only "active phase" of the process.

By the way Data Rate in Mpixels/s is just a LCD controller pixelclock. If we connect our controller to a standard VGA monitor we'll fail( i have video DAC on my LPC4357 board.)
In the real world pixelclock for the standard VGA mode is 25.175 MHz (meaning 59.94Hz instead of 60, but if 60 then 25.2 MHz). Pixelclock MUST be running continiously.

Why there is a difference in a pixelclock rate with your calculation?
Because the 25.2 MHz takes in consideration all kind of synchronizations needed for the LCD/Monitor and there are 800x525 pixels in VGA mode where only 640 x 480 will be seen. But tne time to process non-displayed pixels still is consumed.

So in real life the VGA frame consists of 800x525 pixels. It must pe processed in the same time as yours "ideal" 640x480 frame.

(800x525) / (640x480) = 1.3671875
18.432 * 1.3671875 = 25.2

In both calculation the visible pixel count is always the same. The non-displayed pixels (while LCD controller does send nothing to LCD) allows to increase SDRAM availability for the others AHB masters; these periods can be managed based upon the LCD interrupt routine data.

As to the LCD share in bandwidth eating we must calculate it as follows:

Data Rate in Mpixels/s = 800x525x60 = 25.2
Data Rate in Mbursts/s = 25.2 / 8 = 3.15

Bandwidth needed by LCD = ((15 * 3.15) / 114 ) * 100% = 41.4%

There is an continious interleaving of 41.4% and 0% LCD bandwidth chunks in such way that the average bandwith is exactly 30.3% as per your calculator. From the point of view of LCD FIFO starving and round robin we must calculate the bandwith based on a pixel stream while there is the "active phase". Of course, all these calculations make sense if you have a heavy SDRAM load from the other AHB masters except of LCD controller. Otherwise you don't need to bother at all.

Your calculator is too optimistic and may give the wrongful hope for someone like me :)

Best regards,
zp

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Wouter on Tue Sep 03 01:46:19 MST 2013
Hi zp,

I don't think I fully follow, perhaps you can explain a bit more?

Note that the sheet is only meant to give you an indication of the bandwidth required on the EMC for the LCD controller to refresh the display.
In addition to that, indeed you need to add the bandwidth required to update the content of the framebuffer. Since we don't know how often and how much a customer will update the framebuffer, we cannot add this to the sheet.

Quote:

Though Data Rate is calculated quite right you can use this value if your framebuffer is about the same every frame.

I think you're mixing up two things here; the framebuffer is the same size for every frame, and always the complete frame will be written to the LCD by the LCD controller. How much you change in your framebuffer per frame indeed differs, but as explained before, this fully relies on your graphics library and the content you want to show.
Therefore, the calculated data rate should be equal to the data rate of the EMC required for refreshing the LCD.

Quote:

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%.

There is some additional overhead send to the LCD by the LCD controller (e.g. horizontal/vertical front/back porch) but these values are not fixed and depend on the LCD. for 640x480 LCDs indeed 800x525 is often used, but even for 640x480 LCDs other values are possible. But, since this overhead does not need to be stored in memory, it has no influence on the EMC/AHB bus data rate. Since the sheet only specifies the EMC bandwidth, the front/back porch values do not need to be taken into account

Quote:

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).

A resolution of 640x480, combined with 3D rendering is indeed no easy task, even for a 200MHz dual-core microcontroller. I'm curious to your progress!

Regards,
Wouter