Architecture choices balance cost and performance for embedded graphics applications

by Waqar Saleem , TechOnline India - June 07, 2011

Some application segments—notably automotive—have to keep up with the high-end graphics that are common in smart phones. Designers must ensure that the GDC can create fluid, crisp graphics and that the system responds quickly to user inputs.

From 3D rendering to image warping, the capabilities of today’s graphics display controllers are integral to a broad range of innovative applications. High-end GDCs help define a product’s style and value with dynamic graphics that dazzle consumers. At the other end of the spectrum, modest GDCs display information clearly and simply, giving users what they want efficiently and cost effectively.

Whether simply functional or absolutely dazzling, graphics deserve careful attention and reward good design in highly visible ways. There are basic QVGA display ICs, with pre-rendered graphics that may include video input. The highest level provides SXGA or higher display resolution with dynamic 3D graphics and multiple inputs. In the middle are GDCs with WVGA display (primarily 2D dynamic graphics with some 3D also possible) and video inputs.

Some applications are highly cost sensitive, such as the automotive industry, where one of the top priorities a minimized bill of materials. In basic to mid-level applications, designers can address this need by using system-on-a-chip graphics controllers as a single-chip solution. These GDCs can communicate with other automobile systems via the CAN bus and can go into shutdown power mode to preserve battery power.

Limitations of internal VRAM capacity and bottlenecks like bus speed limit the level of graphic functionality supported, flexibility, pixel fill rate, and maximum display size. If performance is more important than cost, higher-end SoCs based on multi-chip architectures are good choices. These GDCs rely on an external vehicle MCU to handle CAN traffic, power management, and peripherals such as stepper motor controllers. They do not have built-in VRAM and program flash memory, but use high-speed VRAM interfaces to support high performance.



Selection of basic GDC options balance cost and performance


Some application segments—notably automotive—have to keep up with the high-end graphics that are common in smart phones. Designers must ensure that the GDC can create fluid, crisp graphics and that the system responds quickly to user inputs. Thus, the GDC must not impose bottlenecks in the system that create a lag in delivering the desired experience to the end user.

For basic to mid-level applications, a true single chip SoC may be suitable. For high-end applications, such devices will not provide sufficient performance, and a high-end (multi-chip architecture) SoC with external VRAM and flash memory will be needed.

If the product’s display accommodates 24-bit RGB input, a GDC with 24-bit RGB output helps avoid the banding effect (abrupt changes between shades of the same color). The use of 24-bit color ensures smooth-looking graphics. Otherwise, the application may need a dithering function in the GDC for neutralizing the banding effect. Dithering applies randomized noise to the frame buffer to prevent the banding effect due to limited color depth.

While smooth, flashy graphics always have appeal, applications such as industrial electronics equipment that prioritize rugged design and ease of use can get by just as well with more basic graphics functionality. Lower-end GDCs offer surprising performance for many uses without inflating the bill of materials.

Graphics content: Static or dynamic?

The choice of GDC also depends on the nature of the graphics content. If the content is static and can be pre-determined, a low-cost GDC such as a sprite engine may suffice. Pre-rendered graphic bitmaps can be stored in the Sprite GDC’s external flash memory. Such GDCs are very good at handling different color formats (those using a color lookup table or those having actual pixel values in the frame buffer) and can also handle transparency and alpha blending. Use of a low-overhead compression scheme, such as RLD (Run Length Decoder), can greatly reduce storage requirements for pre-rendered graphics, thus reducing cost.

Other applications need dynamic graphics content that is determined on the fly, such as maps or random animation. These applications require a GDC that has a fully functional pipeline capable of rendering 2D or 3D models with texture maps. The application may also benefit from the use of functions such as hardware lighting and fogging. For more complicated tasks, a graphics engine with shaders provides greater flexibility.

Using a flexible display controller simplifies the work of graphics implementation and supports better graphics. Specifically, graphics development is significantly easier with a flexible layering scheme and support for multiple layers and alpha planes, as well as a variety of color depths.

Then there is a choice between 2D and 3D graphics. Using 3D graphics impacts performance and features required from a GDC. For example, 3D applications demand higher rates of vertex processing than 2D applications, along with functions such as perspective correction for texture maps and "mip mapping" needed for 3D graphics. Mipmaps are optimized and resized version of the main texture map that are stored along with the main texture map. They are very useful in enhancing performance by helping avoid the need to resize the main texture map on the fly.

Just adding the z coordinate for 3D graphics significantly increases processing requirements. Two-dimensional graphics rendering is much simpler, and if the content is static, it can be pre-rendered, as discussed earlier. In the cases of dynamic 2D or 3D content, a graphics engine with a full pipeline will be needed.


Resolution requirements

Because larger, higher-resolution displays have more pixels to process, applications that use bigger displays need a faster, more powerful GDC. Avionics and medical applications generally require a 640 x 480-pixel display on the lower end and may go upwards of 1,280 x 1024 pixels on the high end. In the automotive market, display sizes are typically 480 x 272 pixels for low-end clusters and center stacks, 800 x 480 pixels for mid-range applications, and 1,280 x 480 pixels or higher for high-end applications.

Whether you increase the resolution of a single display or add multiple displays, both multiply the number of pixels involved and thus increase the GDC processing requirement, which can be handled using multiple GDCs. Some GDCs have display controllers that can support multiple displays using a single controller. These multiplex video output information, using twice the display or pixel clock frequency as for a single display. The dual displays must have the same timing characteristics and display resolution. This type of GDC is a good choice for auto instrument clusters that have dual displays with identical resolution.

On the other hand, some GDCs integrate more than one display controller and can drive multiple displays that have different timing and resolution. This type of controller costs less than two independent GDCs and simplifies the design. A typical example is an automotive head-up display (HUD), where the HUD has a lower resolution than that of the main display, such as in the instrument cluster area. Another automotive application is to use a single GDC to control both the instrument cluster and center stack displays.

GDCs provide a range of features for displaying video input from a camera or some other source. Some GDCs integrate the analog circuitry needed to support analog NTSC/PAL video input, and these controllers can be useful in basic-level video capture applications. Other GDCs work with digital YUV/RGB video formats or require an analog converter.

Applications that require multiple video captures can take advantage of a higher-end GDC that integrates multiple video capture units. The display controller must also be more powerful to handle the multiple inputs and overlay the video stream(s) onto the rest of the graphics.

Special requirements

Specialized requirements such as image correction and enhancement can also be factors in the choice of GDCs.

Video cameras have inherent fish-eye distortion that deforms the image. If the camera does not have a built-in function to correct the issue, as is often the case, the GDC needs to correct the distortion using a process called image warping. This process maps the video input to a 3D surface characterized to cancel out the fish-eye distortion. The surface is generated from a mesh that consists of a set of (x, y, z) points, as shown in the figure below.



With image warping, a GDC can adjust video for fish-eye distortion for better viewing


Another application of this feature is in automotive head-up displays. Since the image is projected on the windshield, a process similar to the fish-eye correction is needed to adapt the graphics to the windshield curvature.

Image warping requires a GDC with 3D capability. It is also useful if the GDC can scale the resolution of video images up and down.

One application that could become important for automobiles is the use of multiple video cameras around the vehicle perimeter whose inputs are combined into a single image. This application demands the ability to handle high-resolution video and special image processing functions to stitch together the images.

The ideal solution here is a GDC with multiple video inputs and high-speed image processing capabilities, which eliminate the need for an external FPGA to implement these functions with the necessary performance level. Including 3D rendering capability in the GDC allows mapping of the stitched image onto a bowl-like surface, which enables the display of a realistic, distortion-free 360o view around the vehicle.

Image enhancement and object detection can help drivers avoid accidents.
Implementing such features requires special image processing blocks in
the GDC.

Some regions of the world mandate safety functions such as a signature unit — a checksum function that ensures that the graphics content is shown at the correct location on the display panel. Having this capability built-in saves cost and CPU overhead.


Legacy hardware/software support and standalone GDC requirement

Some applications must reuse the CPU from previous designs to support legacy requirements and cannot just be designed from the ground up. These applications can often make good use of standalone GDCs that do not have built-in CPUs and can communicate with the legacy CPU via a memory, PCI, or PCI Express bus. This approach enables a scalable design with a variety of performance levels and
feature sets.

Some applications require the display to be located remotely from the GDC. A high-speed serial bus such as APIX is needed in such cases to transmit the video to the display. This configuration allows use of a client/server architecture, in which the GDC acts as the server and the display as the client. Developing client and server systems independently helps reduce software and qualification costs on the server side because one PCB can be scaled for use across an entire product line. Such an implementation is highly effective if the high-speed serial output functionality is integrated in the GDC.  



APIX high-speed serial bus transmits video to the display




As shown above, Fujitsu offers a wide range of GDCs that span the spectrum of application categories from high to basic. In each category, Fujitsu offers an SoC that integrates a CPU, GDC, and peripherals.

These standalone GDCs are viable options if the system is not being put together from the ground up and there is some legacy component in the system that needs to be preserved.

The range of today’s GDC capabilities makes device selection a crucial part of application development. This selection process is easier thanks to a variety of GDC options tailored to meet various application segments. These GDC choices are feature rich, proven in the industry, competitive, and cost effective.


About the author:

Waqar Saleem is a senior applications engineer responsible for GDCs and MCUs for Fujitsu Semiconductor America. In his past ten years with the company, he has been providing applications engineering support for various products for both
automotive and non-automotive markets. He holds a BSEE from UET Lahore,
Pakistan and an MSE from San Jose State University.

About Author


blog comments powered by Disqus