All Forums
 StrongARM display bandwidth limitations explained
 Forum Locked  Topic Locked
 Send Topic to a Friend
 Printer Friendly
Author Topic  


1519 Posts

Posted - 12 Aug 2002 :  15:51:30  Show Profile  Email Poster
The StrongARM Display Controller: Bandwidth Limitations Explained

The StrongARM SA-1100/1110 processor has an integrated graphics controller designed to drive a wide array of display types and sizes. This article describes the memory model of the StrongARM controller and its limitations.

Important Note: The XScale display controller has significantly improved performance over the StrongARM. See topic 990 for details.

Bus Bandwidth

The StrongARM display controller uses system memory for the frame buffer: Each pixel on the display is read from system memory and sent to the LCD display 30-70 times per second. While providing an economy of silicon, drawing pixel data across the bus imposes limits on the display controller's capabilities.

The controller draws data from RAM in four-word bursts. Data bursting is a feature of synchronous DRAM that increases data throughput on the bus. When a burst cycle is initiated, the SDRAM serves up four or eight words of data synchronously with the memory clock.

The SA-1110 data clock runs at 103 MHz, so data transfer rates can reach 250 MB/s (a burst of eight, 32-bit words takes about 120ns). The four-word bursts used by the LCD controller can reach speeds of 200 MB/s (80ns cycles). While it might appear that this bandwidth would support any size display, there are some additional limitations that must be accounted for when using displays.

Display Data Bandwidth

There are three variables that determine how much data it takes to drive a particular display.
  • Resolution

  • The number of pixels in a display. Standard resolutions (4:3 aspect ratio) include QVGA (320x240), VGA (640x480), SVGA (800x600) and XGA (1024x768).

  • Color Depth

  • Active displays typically use eight or sixteen bits per pixel (bpp). Passive displays are sometimes 4bpp (half byte of RAM per pixel) or monochrome.

  • Refresh Rate

  • Active panels generally require a vertical refresh rate between 30 and 70 Hz. For each vertical refresh, the display controller reads the full frame buffer from RAM.

To calculate the data bandwidth, multiply the resolution, color depth and refresh rate together. For example, an active(TFT) VGA display running at 8bpp and 55 Hz requires 16.9 MB/s of data bandwidth (640 x 480 pixels x 1 byte/pixel x 55 Hz). The panel's pixel clock must run as much as 50% faster to account for vertical and horizontal refresh pauses.

LCD Controller FIFO and Limitations

The panel controller has a five-entry, 32-byte wide FIFO for driving the panel outputs. Each 32-bit entry contains data for several pixels:

Mode Pixels per FIFO entry
4 bpp 8
8 bpp 4
12 bpp 2
16 bpp 2

The controller pulls data from the frame buffer in four-word bursts. When only one entry remains in the FIFO, the panel DMA driver initiates a memory read cycle.

The LCD controller's DMA channels have the highest priority, presumably to prevent the panel driver from getting data starved. However--and this is the key limitation of the current StrongARM architecture--the DMA must wait for the current memory cycle to complete. When bus devices like PCMCIA that have long memory cycles are active, the LCD controller can get starved for data.

As an illustration, a typical 8bpp VGA active panel with a 28 MHz pixel clock has a maximum 280ns window (as many as eight pixel clock cycles--2 FIFO entries X 4 pixels per entry at 8bpp) to get its data before the LCD controller FIFO is completely empty. That window narrows to 140ns in 16bpp mode. It's very easy for a PCMCIA memory cycle, which can last several hundred nanoseconds, to starve the LCD controller.

When the controller runs out of data in the FIFO, it stops the pixel clock until it gets new data. This causes most displays to "tear", a visual effect in which the image jumps back and forth, the image skewing to the left on a diagonal from the bottom. The display is generally not intelligible during these bursts.

Optimizing Display Controller Operation for your Application

There are a number of optimizations that ADS employs to achieve top performance with the flat panel displays we configure for our product. Generally, we will choose the highest refresh rate that works reliably during PCMCIA access. This tends to give a pixel clock rate in the range of 15-25 MHz. We may also trade off lower display refresh rates for improved color depth in applications that require it.

If an application requires a combination of high refresh rates, high resolution(eg. XGA) and/or increased color depth, ADS offers StrongARM solutions with external graphics accelerators. These products offer improved graphics performance through a combination of onboard frame buffer memory, accelerated graphics primitives and the corresponding reduction in system bus bandwidth.

The upcoming XScale processor reduces the display data bottleneck by doubling the depth of the graphics controller FIFO. The XScale processor is slated for release later this year. ADS will be among the first in the industry to release application-ready XScale systems for the embedded market.


While the StrongARM display controller drives a wide range of flat panel displays, embedded developers should be aware that the controller has tradeoffs of display resolution, color depth and refresh rate. Developers can choose from a variety of engineered solutions from ADS to meet their application needs.

For further reading about displays on ADS products, see the display topic index.

Drew Kidder
ADS Technology Transfer

Edited by akidder 18-Jun-2003: Add link to XScale display controller topic.


17 Posts

Posted - 14 Aug 2002 :  19:13:27  Show Profile  Email Poster
We need VGA (640x480) at 16-bit color, to drive a flat-panel LCD.

Now, if I was driving a CRT I would want 60-70 Hz refresh rate, but is that really important for a LCD? I am thinking the LCD pixels have more persistence, and a refresh rate of 40 Hz might be OK? (which comes out to 25MZ bit clock if I calculate correctly?)
Is this true?

Is it only using the PCMCIA that causes the screen to go screwy? If so, since we may only use it for software updates, it may to OK to have the screen blip out for those rare occasions. Would that let us bump up the clock rate?
Go to Top of Page


1519 Posts

Posted - 15 Aug 2002 :  18:03:43  Show Profile  Email Poster
Good questions, Michael. The short answer is that we've been able to successfully drive a number of VGA panels at 16bpp using the StrongARM controller. The longer answer follows....

The acceptable refresh rate for a display depends largely on the display type. Pixels of active panels can change quickly, which makes them well suited for displaying video and animation; the tradeoff is that they require a higher refresh rate than passive displays.

I didn't note in the article above that in addition to PCMCIA and CF access, Ethernet can sometimes cause display distortion. It depends largely on the display timings used.

Contact us with the display we're using and we'll let you know if we've got timings that have been optimized for 16bpp.

Drew Kidder
ADS Technology Transfer
Go to Top of Page
 Forum Locked  Topic Locked
 Send Topic to a Friend
 Printer Friendly
Jump To:
Eurotech Support Forums © Eurotech Inc. Go To Top Of Page
This page was generated in 0.05 seconds. Snitz Forums 2000