The key target market for the RZ/A device is the Human Machine Interface market, for driving medium to large TFT panels. The RZ/A family is an ARM cortex A9 based embedded MPU solution that brings many advantages to the HMI application space. The article will be a discussion of the requirements of such an application space as well as of how the RZ/A meets these requirements and offers system level advantages to the design engineering community. The RZ/A features up to 10MB of embedded SRAM on chip, which makes it the largest embedded RAM in the market and the article will show to make best use of this embedded RAM to optimise both system cost and performance of your HMI system.
Author: Robert Kalman, Product Marketing Manager Industrial Communications Business Group, Renesas Electronics Europe GmbH
In June 2013, Renesas released its newest platform. The RZ/A family is aimed firmly at the Human Machine Interface market, for driving medium to large TFT panels. This is a market expanding at an enormous pace. Before Apple took the world by storm, there was the constant dismissive discussion in technical circles about “who would want to have a colour screen on their telephone?” but we were all proved wrong. Apparently, we all do want a colour screen on our phones. It is not just phones either! The number of coffee machines, refrigerators, vending machines and the likes that are fitted with a TFT panel is set to rise significantly over the next few years. I noticed with excitement that in a number of shops recently the piece of plastic upon which a receipt is normally placed such that you can sign it, has now been replaced by a 7-inch TFT display showing advertising for products available in the store. The rise of “bathroom advertising” from companies across Europe and the world shows that soon there will really be no escape from the TFT panel.
So what do you need for your application?
Let’s start by looking at the heart of the problem. What do you actually need in order to drive a TFT screen? Most TFT panels today use a digital RGB interface, whether that be RGB888 or RGB565. The RGB value is a standard whereby the colours red, green and blue of each pixel are represented by the corresponding number of bits. So for 888 each is given a full 8 bits of data (giving 24 bits per pixel), whereas in 565 the red and blue are represented by 5 bits and the green by 6 bits (giving 16 bits per pixel). Alternatively, instead of a standard digital interface a screen could be using an LVDS connector, as is increasingly becoming the standard with larger screens. As such, the RGB signals are transferred over a differential signal, but the format of the data is still the same. So to start with, you need a device that supports the generation of an RGB signal and / or an LVDS interface.
Second to that, the RGB data has to come from a frame buffer, which is typically stored in RAM. This frame buffer is a bitmap image stored in the desired format. Thus, a screen size of WVGA for example (which is 480 × 800) will need for an RGB888 image just over 1MB of RAM to store the image (480 × 800 × 24 bits = 1.125MB).
In addition to this frame buffer containing the current picture being displayed on the screen, a typical application will have a “back buffer” that contains the next picture to be driven to the screen. This way, the CPU can manipulate the next picture without the user seeing a half-manipulated picture flickering on the screen before the CPU is finished.
This system of double buffering is very common and gives an overall higher quality of HMI, but also means that the WVGA screen needs a further 1.125MB of RAM to store the buffer.
The RAM story is sadly not finished, however. In a typical HMI application it is not always necessary to manipulate the whole screen. For example, if an icon or button is pressed, it might animate, glow, rotate or somehow react prior to the action being taken.
In this case, what an HMI designer would do would be to define a different layer of the picture. There would be a background layer that would be unchanged and the icon or button would be a foreground layer, which would then be animated.
However, this obviously also needs additional RAM, not a full screen but “some” more. It depends on the size of the image, but with a 200 × 200 pixel button we would need an additional 100k of RAM. What is also required here is the ability to blend all these different layers with one another, and perhaps apply a level of transparency to some of those pictures. This can be done in software if the CPU is fast enough, or in hardware if it is available.
So, to complete the RAM requirements story, a reasonable HMI application can use in the region of 3MB as frame data for a WVGA screen size. If the code is running on RAM too, as is the case with most processors, then a further 0.5MB of code is needed.
Thus the starting point for a WVGA screen should be to look for a system with a minimum of 3.5MB of RAM.
Of course, the speed of access to the RAM is also very important. As you will have likely just realised, the RAM here is being written to and read from by several different sources concurrently. For example, the front buffer (the original image data) will be read by the IP block to drive the data to the screen. At the same time, the back buffer will be updated by the CPU or by a DMA transfer of a different image. At the same time as this, the CPU may be manipulating the aforementioned icon, and reading its own code from the RAM. This puts a lot of pressure on the bandwidth of the bus to the RAM. This bus is very often the bottleneck in the application, so a good system of bus architecture is required to mitigate the risk of overloading the bus and of the user seeing some half-finished images, or worse still a non-functional GUI.
Special attention should also be paid to the performance of the CPU. A system delivering 24 frames per second to the screen will need to manipulate and create data (in our example of a WVGA screen) of over 24MB per second. This can be done entirely in software, or in some parts in hardware, but whatever happens the CPU must be fast enough to cover these requirements.
As we are now clearly talking about a processor solution, which is likely not going to have any flash memory on chip, the next requirement is that of a connection to external flash memory. The typical method for today is to use an external parallel NOR flash to store the code and then during boot mode to transfer this code into the RAM to support fast execution. Newer devices, however, support other memory technology to allow system architects to reduce system cost without having the overhead of an “expensive” NOR flash on the PCB.
Most of these applications typically do more than just drive a screen. They need to be connected to the rest of the system too. Automotive applications are typically connected to the CAN or MOST bus. Industrial and consumer devices today generally require Ethernet and USB connections. These connections also mean that the most suitable product will have to not only incorporate the hardware IP, but also have sufficient performance to manage their operation and sufficient code space to support their stacks.
So how about the RZ/A?
The RZ/A family is an ARM Cortex A9 based embedded MPU solution that brings a great many advantages to the HMI application space. The RZ/A features up to 10MB of embedded SRAM on chip, which makes it the largest embedded RAM in the market. There are 3 variations in the family. The RZ/A1H which includes the full 10MB of RAM, the RZ/A1M which has just 5MB of RAM, and the RZ/A1L which includes the lowest 3MB of RAM.
So from the discussion above, where we calculated that the HMI application would need approximately 3.5MB of RAM, the RZ/A1M looks ideally suited to meet these requirements. It is of course possible to find several other solutions on the market that will use external RAM, whether it be DDR or SDRAM, to cover this size of memory but the RZ/A family is the only product that the author is aware of that can offer such a high level of internal RAM.
The RZ/A1H gives the system designer room to increase the screen size and also to decrease the screen size depending on requirements, and create a cost-optimised version for smaller resolution products.
The 400MHz CPU performance is more than enough to run a simple HMI application and maintain communication through whichever protocol the system dictates, because all versions of the RZ/A family include CAN (up to 5 channels) Ethernet, USB (up to 2 channels) and even support MOST in the automotive qualified versions.
In fact, the 400MHz CPU is more than enough due to two unique features of the RZ/A. The first feature is the VDC.
The video display controller from Renesas supports in hardware many of the functions required for creating the final screen image. The VDC will support up to 4 different graphics layers, two of which can be inputs from an external camera. It will also support alpha blending hardware. Alpha blending is a process whereby each pixel is allocated an additional 8-bit alpha value.
This alpha value determines the transparency of the pixel, such that it can be overlaid on top of another pixel to create the resulting image. The VDC also supports chroma-key operation, the most well-known use of which is in “green screen” videography, where a particular colour is defined as transparent so that an object can be overlaid again on another picture. In some systems all of this would be done in software, but the RZ/A does it in hardware, thus the 400MHz in reality equates to a much higher equivalent performance. The VDC also supports the RGB digital connection to a TFT screen as well as the LVDS.
The second performance factor of the RZ/A family that boosts the CPU performance is the removal of the bus bandwidth problem we saw earlier. A quad-core terahertz processor is only as fast as it can get the data. When that data is all stored in a single RAM block to be accessed over a single bus, this is bound to slow down the core. The RZ/A, in contrast, has 5 separate RAM banks. Each bank is connected to its own dedicated 128-bit wide bus, such that it is actually possible to both write to the back buffer, read from the front buffer, manipulate an icon and complete a DMA transfer all whilst running code from the internal RAM. This is a significant performance boost.
Of course, we mentioned earlier that a connection to external flash memory is also needed, and the RZ/A supports all the normal connections to non-volatile memory such as NOR, NAND, SDIO, MMC etc. However, it also has a special SPI Multi-I/O serial flash connection, which supports the new quad SPI protocol. This QSPI can achieve similar or better performance figures to those of parallel flash while providing the economic advantages of serial flash, as well as saving pins on the microprocessor and reducing PCB size.
Simply put: The RZ/A is simple
The newly released RZ/A device from Renesas has been specifically designed for the Human Machine Interface market. There are several requirements in this market which are not unique on their own, but their combination makes the market a difficult one to cover with traditional systems. The need for RAM is large, but not so large that a microprocessor with 128MB of DDR3 RAM is required.
The performance requirements are low, as long as the device is supported by a well-designed display controller, but they are not so low that a microcontroller running at, say, 100MHz could cover them.
The RZ/A contains just enough connectivity for any HMI application, more than enough performance, and a good amount of RAM allowing for flexibility. It is a cost optimised and dedicated solution that will not only profit from the booming market for display technology but also help drive it forward.
Renesas Electronics Europe
www.renesas.com