ACCELERATING 2D GRAPHIC APPLICATIONS WITH LOW ENERGY OVERHEAD

Transcription

1 ACCELERATING 2D GRAPHIC APPLICATIONS WITH LOW ENERGY OVERHEAD Oliveira, L.; Neves, B; Carro, L Instituto de Informática Universidade Federal do Rio Grande do Sul {loliveira,bsneves,carro}@inf.ufrgs.br ABSTRACT Following the growth of embedded systems market, especially PDAs and mobile phones, the digital entertainment market, based on those platforms, grows as well. This scenario makes it important to address energy consumption on graphical applications, since many devices use some kind of display. This work presents a class library for low energy graphical applications running on embedded systems based on Femtojava microprocessor. 1. INTRODUCTION Along with technology evolution, the use of electronic systems increases with the intent of aiding in our everyday tasks. Electronic devices designed to several uses are more and more common. These devices are used for entertainment, communication, control of mechanical devices, etc. These devices are called electronic embedded systems. Following the ever-increasing demand for electronic embedded systems comes the need to reduce the time-tomarket of such systems. The designers need to finish a quality product, on time, on budget, and in accordance with consumer needs. Several commercial issues impose such constraints on the design of new products. The ever-increasing complexity of embedded systems only complicates matters. The consumer will buy a new product only if it brings new features that are important to him/her. Additional features complicate design, making it even more difficult to meet the requirements on time and on budget. To handle these issues, new methodologies are proposed in academia, aiming at reducing design time. These methodologies, more often than not, propose to specify the system in a higher abstraction level. With each methodology comes a set of tools to support its philosophy of design. Unfortunately, the use of such methods is very restricted, and very few make its way to wide use. Another way of reducing design time is the use of libraries of pre-designed and pre-validated components, both in hardware and software. Ease of use is very important in such libraries, in order to make its use worth. Integration is a very complicated problem, since components often come from different vendors and each of them can use different communication strategies. It is true that there are several efforts in standardizing communication methods in electronic systems, but the reality is far from ideal. On the software side the problem of integration also manifests, but it is clear that well designed software libraries help to reduce design time, since the developer can focus on the functionality of the systems rather than on low level functions. Restrictions imposed by embedded hardware contribute to increase system complexity. The Java language presents some characteristics that proved to be important in the design of complex systems, such as simplicity, portability, scalability (through object orientation), small code size, and so on. This work presents a class library designed to ease the development of embedded two-dimensional graphical applications. By doing that, it goes a step further in the path to provide a embedded platform based on Femtojava microcontroller. The library, called FemtoGraphics, was developed aiming low energy consumption by using simple techniques based on pre-processing of data to reduce memory accesses during execution time. Section 2 describes related work. Section 3 describes Femtojava, our hardware platform embedded systems. Section 4 and 5 describe the library and the optimizations performed on it to reduce energy consumption. Finally, section 6 shows some results and future work. 2. RELATED WORK The design of embeded software presents some problems. Portability in embedded systems, even with the use of Java is no trivial problem. Embedded systems have varied 1

2 features, making portability less straightforward than on desktops. Java 2 Micro Edition (J2ME) is a platform for resource-constrained environments. J2ME features virtual machines, configuration and profiles for various environments and several needs. With a proper configuration and profile, J2ME applications can execute in several devices, like cell phones, PDAs, set-top boxes, etc. A Java virtual machine with main libraries, classes and API constitutes a J2ME configuration. Connected Device Configuration (CDC) contains the CVM virtual machine. This configuration is directed to devices with 2MB of memory or more for the Java platform e often connected to some kind of network [12]. Connected Limited Device Configuration (CLDC) includes the K virtual machine or the CLDC HotSpot virtual machine. The K virtual machine is meant to RISC or CISC processors, 16 or 32 bit, and only 160KB to 512KB of memory for the Java platform. CLDC HotSpot is the next generation virtual machine for mobile devices. It features higher performance and includes connectivity do some kind of network, generally wireless, with limited bandwidth. CLDC takes into consideration energy consumption issues [13][14]. Profiles further define the J2ME environment, specifying the adequate platform for each device. Personal Basis [17] and Personal [18] are profiles for CDC configuration. The Personal profile is a superset of Personal Basis profile. Both are based on the Foundation profile and both allow the development of Java applications for consumer electronic devices. The MIDP profile is the basis for CLDC configuration. The PDA profile is meant to PDA devices and includes MIDP, introducing the Personal Information Management API [19]. There are also other solutions for embedded systems that are not Java-based, like Binary Runtime Environment for Wireless, from Qualcomm [4] and.net Compact Framework, from Microsoft [5]. The existence of such systems is further evidence of the need to promote the reuse of components, through libraries, in order to reduce development time of embedded systems. These systems ease the access to system peripherals in a device independent way, making code more portable. 3. FEMTOJAVA Due to the adoption of Java on cell phones and PDA devices [7], comes the need to improve the efficiency of software on the Java platform. The Femtojava microcontroller [1] executes Java bytecode directly, without a virtual machine. Femtojava has a reduced instruction-set, Harvard architecture, low area cost and the possibility to synthesize a custom processor, removing some instructions.. Such process is done through a tool called Sashimi, which analyses Java bytecodes and generates a control path that supports only the instructions that are actually used. In [2] a low energy version of Femtojava was described. There are other hardware implementations of Java machines, such as Picojava-I [8], Picojava-II [9], Komodo [10] and TRAJA [11]. The Femtojava microprocessor executes a limited set of Java bytecodes. It has some constraints that should be respected when developing applications on it. These constraints are a result of executing bytecodes directly in hardware. Some features are simpler to implement in software, like dynamic memory management. Our memory management system is a software library that is linked to the applications. This library was designed to contain only methods that respect the restrictions of Femtojava. More over, the library is restricted to creation and manipulations only of objects which class file contains code supported by the Femtojava hardware. Actually, this poses an import problem, since it restricts the set of applications we can use to validate Femtojava extensions like the one proposed in this paper. Many efforts are currently in development to circumvent this problem and enhance Femtojava support for different applications. The dynamic memory management library was the first extension of the instruction set completely implemented in software. It uses a code adaptation tool that automatically replaces dynamic memory management instructions for static method calls to the library. 4. FEMTOGRAPHICS LIBRARY The FemtoGraphics library was conceived to be a simple way to create graphical application for embedded devices based on the Femtojava microprocessor. It was designed to have a small memory footprint, by implementing only primitives on top of which a more complex application can be designed. This section presents the non-optimized version of the library. An important component of the FemtoGraphics Library is the Femtojava Resource Compiles (FemtoRC) which generates Java code from image files. Other types of resources are planned, but currently only images are supported by the tool. This tool not only transforms images into Java source files, but also is the offline pair to the techniques described in the next section, that are used to reduce energy consumption. The tool takes as input a set of file names and output a file called Resources.java that contains the data of all image files converted to the color format of the runtime library, according to some parameters that control how the images are stored and manipulated. After generating the resource file from the images, that file should be compiled with the application. The application is designed using a restricted set of Java 2

3 functionality, given the constraints of our environment. The library is designed with these constraints in mind. The main class of the library is FemtoSystem. It is responsible for holding access to the frame buffer and is planned to be the access point to other features in the future. The most important class in the library is the one that holds image data, called FemtoImage. FemtoImage has all methods used to control access to images. Among them, the most important are the block transfer methods, which are responsible for copying the image data to the frame buffer. The class Screen is composed by a FemtoImage object which represents the frame buffer itself. There should be only one Screen object in the system, and that object can be accessed by calling the FemtoSystem.screen() method. 5. REDUCING ENERGY CONSUMPTION In order to reduce energy consumption two techniques are evaluated, run-length encoding and images as immediate operands. These techniques are used to reduce memory accesses. Since memory accesses are an important factor in energy consumption, by reducing them we also reduce energy consumption. The first technique is to use run-lengh encoding (RLE) compression on images. This leads to less data memory use, which maps to less reads from memory (iaload bytecode). In our implementation we used RLE on each line of the image separately. This was made to simplify clipping, which is necessary if images transit beyond screen boundaries. Clipping is not currently implemented, but is such a common function in games that it must be possible to implement it efficiently. The image compression is done by the same tool that compiles images to source code. In the case of RLE compression, the arrays are generated with different row sizes, depending on the compression. A flag in the resources source file is set to signal that the encoded images are compressed. RLE compression works as follows: if a color repeats itself in a sequence, a value is placed on the compressed image to indicate the number of times that color is repeated. The usual implementation is to use a threshold. If the value is above that threshold, it is not a color, but a repeat count for the color that comes next. In such implementation, the range of colors that is above the threshold value is always represented by a repeat count and the color, even when the repeat count is one. Our implementation uses negative values to mean repeat counts, which limits our color depth to 15 bits, or colors. However, the technique can be used without this limitation and even with higher color depth. The choice of using negatives values is due to the fact that the implementation uses the short data type, and integers in Java are signaled. The output file of FemtoRC is the resource file with all images compressed through RLE. That file should be compiled with the application. Then, the runtime library will uncompress the image at the moment when it will be transferred to the screen. The runtime cost of this operation is very low, since RLE is a very simple compression technique. Also, the number of memory accesses is reduced, making this method even faster than transferring an uncompressed image. Another benefit of RLE happens when using color keys. The test that determines if a color repeated several times should be written is only made once since the result of the test will be the same. That represents less comparisons and more important, less braches in code, making it more efficient and helping to keep the Femtojava pipeline as full as possible. However, RLE will not work all the time. Images where color do not repeat very often are likely to have a low compression rate, sometimes making the compressed image almost as large as the original, or sometimes larger, depending on implementation. For example, if the values above the threshold are valid color and the image does not have color repeating in a line, the resulting encoding will be larger than the uncompressed image. The second technique reduces memory accesses by placing image bytes directly as immediate operands in bipush and sipush operations. Previously, the image pixels were loaded from memory through iaload operations. That meant three bytes, one for the bytecode, one for the array address and one for the offset, plus the access for the pixels itself (two bytes on the current implementaion). By placing the pixel data as immediate operands we reduce memory accesses. The original process of transferring an image to the screen is calculate an index to the source image data, accessing the array to read the pixel, test if it is transparent, if it is not transparent calculate an index to the destination image (screen frame buffer), and writing the pixel to this image. Many of these operations can be simplified by using our second technique. The first simplification is that there is no calcutation of indexes to the source image, since the data will be placed directly in the code. For example, the following is the original code that copies one pixel from the source image to the destination image: Dest[y+i][x+j]=source[i][j]; Where x, y, i and j are all variables. This will become: Dest[y+K][x+L]=value; Where x and y are variables and K, L and value are constants. It is important to see how the bytecodes for these operations will be. The first would result in sload (short load) operations for the variables, two sadd (short add) operations for the additions, one getstatic for each 3

4 array, and two iaload operations (arrays are bidimentionals) for each array. The second will use only one getstatic, three sipush operations, one for each constant, two sadd operations and finally one sastore (short array store). The real difference in energy consumption will come from less memory accesses, since the pixel data is a direct operand of the sipush operation. There are less ROM accesses (only one sipush against getstatic, two sload operations, and saload), and less RAM accesses (only to store the pixel through sastore). A further advantage is that code for pixels that are transparent (equal to the color key) is simply not generated. That will result in even less memory usage and more efficient code. 6. RESULTS AND FUTURE WORK The following table shows the number of cycles to display 13 frames of the application that we used to evaluate the proposed techniques. Our application is a simplified implementation of the Sokoban puzzle game. Original RLE Immediate Cycles (x1000) 2,766,422 2,603,266 1,012,032 Instructions 2,272,001 2,137, ,081 (x1000) Energy (nj) 1.488e e e9 The implementation using RLE compression did not produce good results. One explanation is that it relies on an additional loop to decompress images, resulting in poor usage of the Femtojava pipeline. The immediate operands method produced great results due to the fact that it removed some operations that require memory management. Our memory management system is implemented in software, making it very expensive. So, any reduction in that area brings huge savings in terms of energy and execution time. For that, we had an execution time that is 36% of the original implementation and an energy cost that is 38% of the original implementation. Following this work, we will expand the presented methods and investigate other mechanisms to reduce energy consumption in embedded graphical applications. A pipeline aware version of the RLE method will be considered. If the pipeline aware RLE produces good results, we will consider combining both methods. Also, we will evaluate the methods without memory management overhead. 7. REFERENCES [1] Ito, S.A., Carro, L., Jacobi, R.P. Making Java Work for Microcontroller Applications, IEEE Design and Test of Computers, vol. 18, n. 5, p [2] Beck F., A.C.S.; Carro, L. Low Power Java Processor for Embedded Applications, VLSI-SOC 2003 IFIP 12th International Conference on Very Large Scale Integration, Germany, December, [3] Mobile Information Device Profile (MIDP). Available at [4] Binary Runtime Environment for Wireless (BREW). Available at [5].Net Compact Framework. Available at [6] Sangiovanni-Vincentelli, A.; Martin, G. Platform-Based Design and Software Design Metodology for Embedded Systems. IEEE Design and Test, vol. 18, no. 6, pp , Nov- Dec, [7] Lawton, G. Moving Java into Mobile Phones, Computer, vol. 35, n. 6, pp [8] O Connor, J.M.; Tremblat, M. Picojava-I the Java Virtual Machine in Hardware, IEEE Micro, vol. 17, n. 2, Mar-Apr. pp [9] Sun Microsystems. Picojava-II Microarchitecture Guide. March, [10] Kreuzinger, J.; Marston, R.; Ungerer, Th.; Brinkschulte, U.; Krakowski, C. The Komodo Project: Thread-based Event Handling Supported by a Multithreaded Java Microcontroller, 25th Euromicro Conference (EUROMICRO), pp September, [11] Shimizu, N.; Naito, M. A Dual Issue Queued Pipelined Java Processor TRAJA Toward na Open Source Processor Project, Proceedings of Ásia Pacific Conference on ASIC (AP- ASIC), pp [12] Sun Microsystems. Connected Device Configuration (CDC) and the Foudation Profile Available at [13] Sun Microsystems. The CLDC HotSpot Implementation Virtual Machine, Available at HI WhitePaper.pdf. [14] J2ME Connected, Limited Device Configuration, Available at [15] Choi, I.; Shim, H.; Chang, N. Low-power color TFT LCD display for hand-held embedded systems, Proceedings of International Symposium on Low Power Electronics and Design,. pp August,

5 [16] Choi, I.; Kim H.S.; Shim, H.; Chang, N. LPBP: Low-Power Basis Profile of the Java 2 Micro Edition, Proceedings of the 2003 international symposium on Low power electronics and design, Seoul, Korea, pp [17] Programmer s Guide - J2ME Personal Basis Profile, Available at: [18] Programmer s Guide - J2ME Personal Profile, Available at: [19] PDA Profile for the J2ME Platform (JSR-75), Available at: 5