Making the most of your Graphics RAM

Technology News | March 7, 2011

By eeNews Europe

Automotive instrument clusters used to be simple, no-nonsense affairs. One or two large gauges for speed and engine revolutions, some smaller gauges for fuel level and water temperature plus a few LEDs were enough (plus a large relay to make that tick-tick noise when you turned the indicator on). Nowadays designing an instrument cluster is a whole different ballgame. Modern cars have so many different safety systems, driving aids and informational systems that providing a status display to the driver in a clear, unambiguous and attractive way is a real challenge – there is simply not enough space to do this with warning LEDs, even if it were possible. The only solution is to use a configurable LCD to display different information depending on the situation.

Usually a mix of traditional gauges and a reconfigurable LCD panel is employed, because gauges are less expensive and well understood by drivers. The possibility of animated colour graphics provides a new way of making an emotional connection to the driver while at the same time introducing new challenges to meet safety standards for display of critical information. For mainstream high-volume cars all this must also be done within strict cost constraints. The result is that the instrument cluster design engineer is being pulled in two different directions – the first is toward more powerful graphics processors and bigger graphics RAM to control more complex displays; and the second is toward low BOM cost, single-chip solutions to reduce cost. One way to resolve this paradox is to make better use of on-chip graphics RAM, because SRAM is the most expensive user of silicon area in modern deep submicron semiconductor devices.

This paper describes the challenges faced by designers of modern automotive instrument clusters, and introduces a new approach which removes the need to store complete frame buffers in RAM, thereby reducing RAM size needed to support large displays. This method also allows images to be stored at an optimum resolution, thus reducing the non-volatile memory requirement as well.

Instrument Clusters past and future

Figure 1. Simple Instrument Cluster

Figure 1 shows a picture of a traditional “gauges plus LEDs” instrument cluster from a typical family car of the 1990’s. There is also a small segment LCD to show the odometer and trip readings. In terms of digital technology, very little is required to control this instrument cluster – it can be done with a single 8-bit or 16-bit microcontroller. The software that runs on it is also relatively simple, and there is no need for graphics processing at all. It should also be mentioned that this type of instrument cluster is very inexpensive – most of the viewed area is made up of painted plastic.

Fig.2 Modern Hybrid instrument cluster

Figure 2 shows a preview of the instrument cluster from a recently announced Hybrid Electric Vehicle. It has only one traditional analog gauge mounted in the centre, flanked by two configurable colour LCD panels. The LCD panels display different information depending on the driving mode: when the internal combustion engine is powering the vehicle, engine RPM are displayed; when running under electric power, the battery output power and electric motor output power are shown, and so on. Many other vehicle data are shown in graphical form and the display can be customized to show the information preferred by the driver. The instrument cluster is even designed to “coach” the driver to a more economical driving style – a part of the display can show multiplying green leaves when the driver is being parsimonious with fuel.

Although this is only one company’s take on how colour LCD panels can be used in an instrument cluster, it does show how graphics can be used to expand the utility of the cluster and to add to the showroom appeal of the vehicle. Many other makers of hybrid vehicles use colour displays to show the driver how their vehicle’s complex drivetrain is working, and whether it is currently storing energy in the battery or using it up. No wonder iSuppli is forecasting that sales of in-vehicle colour displays will grow from 20 million units in 2009 to over 50 million units in 2015.

Safety Systems impact the Instrument Cluster

In the past much of the focus of automotive safety systems was on mitigating the effects of an accident – seat-belt pretensioners, airbags, and more, sought to minimize injury in the event of an accident. In the future, the emphasis will change to avoiding the accident or helping the driver to be safe: the roll call of so-called Advanced Driver Assistance Systems (ADAS) now being developed and deployed to automobiles includes adaptive cruise control, adaptive front-lighting, blind spot monitoring, lane departure warning, parking assistance, driver attention monitoring, night vision assistance and traffic sign recognition.Strategy Analytics forecasts a 63 million unit market for ADAS by 2013.

Many of these systems need to provide warnings to the driver or signal that they are active. This information needs to be communicated in a clear and intuitive way; once again designers of instrument clusters are turning to graphical displays to help with this communication. Some production cars already include a Traffic Sign Recognition system which uses a camera and image processing to recognise traffic signs by the roadside. It then shows them on a graphical display in the instrument cluster so that the driver always knows the speed limit that currently applies.

So we have established the requirement for graphics in the instrument cluster. Now let’s explore some different implementation approaches.

How to add colour graphics without exploding the cost

The most straightforward way to add support for a colour LCD panel is to take an existing microcontroller-powered instrument cluster and add a graphics processor (GPU) to do the graphics. This has the advantage that a lot of the existing MCU code for driving gauges and for vehicle communication can be re-used. However it has some important drawbacks:

High bill of materials cost. The GPU requires its own dedicated dynamic random access memory (DRAM) and flash memory devices, so the bill of materials is high.
The need for fast access to DRAM also requires a move to a more expensive 6-layer printed circuit board (PCB). Since cluster PCBs tend to be large, this can have a big system cost impact.

This architecture has been used in several first generation graphical instrument clusters. However, in order for this type of cluster to be sold in more mainstream cars, we need to address the system cost issues. To do this it would be helpful to integrate as many of the above components into a single device.In particular, we want to eliminate the external DRAM so that fewer PCB layers are needed.

Second generation products which integrate the MCU with the GPU are now coming to market. Some are also addressing the DRAM problem. But first, let’s examine why such a large RAM is needed.

Conventional double frame-buffer graphics

In conventional double frame-buffer graphics, as shown in figure 4 below, two memory blocks are used, each able to contain all the information needed to display a single frame. One of these blocks, or frame buffers, is read by the display controller and its contents are displayed on the screen. This happens several times a second, at the refresh rate of the LCD panel, typically 60Hz. In the meantime, the second frame buffer is used by the processor to build up the next image to be displayed. When that image is ready, the two buffers are quickly “swapped”, i.e., a pointer is updated that tells the display controller to read the other frame buffer instead. This swap has to be carefully synchronised to avoid displaying an incomplete frame.

Figure 3, Conventional Double Frame-Buffer Graphics

The amount of graphics RAM needed to support the double frame-buffer approach is usually at least three times the display resolution, in order to support 2 frame buffers plus additional dynamic storage for images. For example a 400×240 resolution display with 16 bits per pixel (bpp) colour depth requires 2 x 400 x 240 x 3 = over 500KBytes. If the colour depth is increased to 18bpp or 24bpp, this doubles the graphics RAM requirement as 32-bits must be reserved for each pixel. Additional frame buffers may also be used to allow complex images to be built up by blending many planes together. So graphics RAM requirements can easily exceed 1Mbyte for a 400×240 pixel display using conventional double-buffer methods.

Novel Fragmented Frame Buffer Graphics

A new approach to graphics is pioneered by the Freescale MPC5606S graphics microcontroller. The MPC5606S contains a special display control unit (DCU) which can build up an image from its many elements, blending them together on the fly and sending the result directly to the display without the need for buffering. The blending is done in hardware and synchronised to the display refresh rate so that only fully complete, blended images are shown on the screen. With this “Fragmented Frame Buffer” method, there is actually no full frame buffer stored in memory at all. There is only one time that all the elements of a frame come together and that is during the on-the-fly blending process inside the DCU, just before the image is sent to the display. As a result of this unique architecture, the MPC5606S can easily drive a 400 x 240 pixel display with only 160KB of on-chip SRAM – no other graphics RAM is needed.

Figure 5 below shows the Fragmented Frame Buffer approach, where many image fragments located in different places in memory, are fetched and blended on-the-fly by the DCU.

Figure 4, Fragmented Frame-Buffer graphics on the MPC5606S

In addition to not needing frame buffers, the DCU has a number of other advantages which minimize the size of the needed graphics RAM:

Images can be stored in flash memory as well as in RAM. The DCU can read and display images directly from flash memory. On-the-fly format conversion. Images can be stored in memory at the minimum necessary colour depth. For example, some images can be stored at 4bpp in memory; the DCU then takes care of converting them to the screen colour depth on-the-fly as it reads them from memory. This means images take up only the minimum needed memory space. Simple Animation for free. Any image fragment which is used by the DCU can be relocated anywhere on the display simply by changing a value in a register. This allows the image fragment to move around the screen with an animation frame-rate the same as the display refresh rate. Also the image fragment to be displayed is obtained via a pointer to a memory address. By changing this pointer one can load a different image almost instantly. Pre-rendered images can be used to achieve impressive effects such as a rotating 3D model of a car, or high-quality gauge needle animation.

A Closer look at the DCU

The DCU of the MPC5606S is a uniquely enhanced LCD display controller which integrates a direct blitting and blending engine. The DCU is able to fetch image fragments from different memory locations, manipulate them, blend them and effectively assemble the frame buffer on-the-fly just before outputting it to the display. The complete frame buffer does not ever need to be stored in memory, greatly reducing on-chip memory requirements. In addition, the DCU supports many different and flexible ways to combine the image fragments. While there are some limitations, the DCU can achieve graphics effects equal or better than those of much more complex, expensive and memory-hungry graphics processors.

Layers and Planes

The DCU can blend up to 16 image fragments or “layers” arranged on up to 4 “planes”. Many layers can co-exist on the same plane as long as they do not have any overlapping pixels. Normally it’s quite easy to build a “scene” required for an instrument cluster with these 16 layers. Before merging the 16 layers, the DCU performs format conversion so that all of the images are represented as 32 bits per pixel (bpp). Of course this means images don’t have to be stored at 32-bit in memory if it’s not necessary, reducing the amount of memory used.

Flexible Blending

The DCU supports both alpha blending (level of transparency) or chroma keying (treats colours within a range differently) or some combination of the two to merge the 4 planes on a per-pixel basis. These techniques are extremely useful for switching a light on/off or dimming, or for drawing anti aliased text against an unpredictable background, such as streaming video. Special alpha map formats produce 32bpp results from a 4- or 8-bit source pixel.

Animation

Since the position of each layer is determined by a value in a register, it is easy to move an image around the screen by simply writing a different value to the appropriate register. Equally, the memory location from which the image is fetched is also a register value. This means relatively complex, high quality animations can be achieved by selecting different pre-rendered images on a frame by frame basis and changing their position on the screen. The rotating car and animated gauge needle seen on the Freescale demos (see https://www.youtube.com/freescale#p/u/58/V-rFl1ogIkw) are examples of this.

Graphics Tools

A novel graphics controller architecture such as the DCU also requires some new tools for creating graphics. Developing high quality graphics and ensuring seamless and reliable operation on an instrument cluster is a challenge and can benefit from automated tools. On the other hand, automatic graphics generation tools can be inefficient users of graphics RAM, which as we already know is a key driver of system cost.

For the MPC5606S, Freescale is working closely with third party graphics tools vendors to ensure their tools make optimum use of the DCU, while keeping RAM usage to a minimum. In addition, a semi-automated approach is offered which enables simple translation of animations developed in Adobe Flash®.

Why Start From Adobe Flash ?

Most graphical designs are created by graphic artists using desktop tools such as Adobe Photo Shop ™ and Adobe Illustrator™. These may also be imported to Adobe Flash to create animations. So if Adobe tools are typically the starting point for all graphics, wouldn’t it be great if we could easily convert animations running in Flash to graphics running on a real embedded system? With the DCU, it turns out that if we can live with some limitations on the original graphics, we can.

Adobe Flash is based on a concept of images which are manipulated in different layers that are then overlayed with each other. This is strikingly similar to the 16-layer system of the DCU. So, our semi-automated approach for translation from Flash uses two tools:

1. Document explaining restrictions that must be applied to the original Flash animation; e.g., maximum 16 layers to be used

2. Library of standard graphics routines, e.g., ‘tweening’ (‘tweening’ in Flash is the concept of extrapolating the intervening frames between a start and finish position, the position being a key frame)

The flash to DCU conversion is done by taking a Flash .swf file and then manually converting the file into C code routines with the help of the standard graphics library. Since the flash layers map directly onto the DCU layers, the images to be used are already available, and the graphics library supports keyframe animations; this manual conversion is quite straightforward. This method also allows the programmer to ensure optimum memory usage and to add additional code as needed.

The result is graphics running on the embedded system that look exactly like the original Flash animation (frame by frame accurate) and efficient use of available memory resources. Most of the examples and demonstration graphics made by Freescale for the MPC5606S have been made with this semi-automated conversion process.

Reducing System Cost

In additional to minimizing the size of graphics RAM required, it is necessary to attack all the other areas responsible for cost in the system, namely:

PCB cost
Power supply
External memory
Software and development tools
Sound generator
Gauge drivers
Communication peripherals such as LIN and CAN controllers

Ideally, as many of the above functions as possible should be integrated with the graphics MCU so that fewer additional components are needed and a low-cost PCB manufacturing process can be used.

The MPC5606S successfully integrates nearly all of the needed components for instrument cluster systems including 6 gauge drivers (with patented stepper stall detect technology allowing for self-calibration), CAN and LIN interfaces, PWM outputs for sound generation, low-power 32kHz oscillator and real time clock, as well as a 1.2V regulator. An AutoSAR compliant software package is available from Freescale which has already been approved by major Automotive OEMs.

Another key feature of the MPC5606S is its QuadSPI interface for connecting low-cost serial flash memory devices. This allows a large database of images and fonts to be stored in a cost-effective way. The simple serial interface avoids the complexity of a parallel memory bus with attendant EMC concerns. Serial flash memories are available in various memory sizes but with the same PCB footprint, so that it is easy to scale the memory and cost to suit the amount of data that needs to be stored.

This, together with the simple QFP package options, allows a complete instrument cluster to be built on a simple 2-layer PCB.

Conclusion

The trend in automobile design is to use ever-increasing amounts of electronic systems to reduce fuel consumption, and to keep the occupants safe and entertained. The result is a huge challenge to the design of the car information systems which must keep the driver informed about what is going on while minimizing distraction. Developers of instrument clusters are turning to colour graphical displays for their versatility and reconfigurability, not to mention their ability to engage with the driver and even attract customers in the showroom.

To meet the challenge of delivering advanced graphics at an acceptable system cost, Freescale has developed the MPC5606S. Using an innovative fragmented frame-buffer approach, stunning graphics are possible with a very small graphics RAM. Together with a high level of system integration, advanced graphics are now within the reach of mainstream vehicles.

About the Author: Jim Bridgwater is Global Segment Marketing Manager, Driver Information Systems for Freescale Semiconductor. He can be reached under Jim.Bridgwater@freescale.com