Cosimulation of ITRON-Based Embedded Software with SystemC

Cosimulation of ITRON-Based Embedded Software with SystemC Shin-ichiro Chikada, Shinya Honda, Hiroyuki Tomiyama, Hiroaki Takada Graduate School of Information Science, Nagoya University Information Technology Center, Nagoya University {chikada, honda, tomiyama, hiro}@ertl.jp Abstract This paper presents an RTOS-centric timed cosimulation with SystemC for embedded system design. In our cosimulation environment, a SystemC simulator and an RTOS kernel model are communicated and synchronized with each other. Our experiment using a JPEG decoder example demonstrates an improvement in cosimulation speed over traditional HDL-based cosimulation. I. INTRODUCTION The functionality of embedded systems as well as the pressure to time-to-market has been continuously increasing in the past decades. Simulation of the entire system including both hardware and software from early design stages is one of effective approaches to improve the design productivity. A large number of research efforts on hardware/software cosimulation have been made so far. Real-time operating systems (RTOSs) have become one of the important components in embedded systems. Therefore, in order to validate the entire system functionality, RTOS has to be simulated together with application software and hardware. However, few studies on cosimulation in the past pay enough attention to RTOSs. In our past study, we have developed a hardware/software cosimulation platform which fully supports an RTOS [1]. The platform provides a complete simulation model of a standard RTOS, which is executable directly on a host computer. On the hardware side, HDL simulators as well as functional hardware models in C/C++ can be connected to the platform. However, cosimulation with HDL simulators is inevitably slow, while cosimulation with hardware models in C/C++ suffers from the inaccuracy of synchronization between hardware and software. This paper describes a refined cosimulation platform which overcomes these problems. The refined platform enables cosimulation with hardware models written in SystemC. On the cosimulation platform, all of the application software, RTOS, and hardware modules are directly executed on a host computer, which leads to high cosimulation speed. Synchronization between the SystemC simulator and the RTOS simulation model is also realized. This paper is organized as follows. Section 2 surveys related work on hardware/software cosimulation with RTOS supports. Section 3 describes principles and implementation of the cosimulation platform which we have developed. Section 4 describes communication and synchronization mechanisms between hardware and software. A case study using a JPEG decoder application is presented in Section 5. Section 6 concludes this paper with a summary. II. RELATED WORK In the past studies on hardware/software codesign and cosimulation, little attention has been paid to RTOSs regardless of their important role in embedded systems. Many earlier studies assume that codesign starts with system specification written in a software programming language such as C/C++. However, specifying the system functionalities in C/C++ alone is not feasible since C/C++ cannot capture concurrent execution of multiple tasks which communicate with each other. In fact, these early research efforts assume a very simple system model consisting of a single or a few application task(s), and do not take account of RTOSs. Some other studies assume that the system specification is represented as abstract models such as task graphs. Using these models, it is possible to describe concurrency without RTOSs. However, most of the past studies using the abstract models did not provide any practical solution to simulate the specification. In the design of complex embedded systems, however, it is very important to extensively simulate the system specification in order to validate the functional correctness. Recently, some researchers have developed generic RTOS models using system-level description languages (SLDL) such as SystemC and SpecC [2], [3], [4]. The RTOS models are used for native execution of application software including RTOS service calls. After simulation-based validation, the RTOS calls are replaced with the system calls of the actual RTOS which is used in the final implementation to obtain the final software code. In [5], a method which automatically generates RTOS-dependent software from SystemC description is presented. The method replaces SystemC s constructs for concurrency and communication with corresponding RTOS service calls. In this sense, it can be considered that SystemC involves a simple RTOS model in itself. A common weakness of these RTOS models is that they support only a limited set of RTOS services in order to make the models generic and independent of specific RTOSs. For example, the RTOS model in [3] supports only 16 service calls. However, even small kernels of actual RTOSs provide much more services. For example, Standard Profile of µitron [6], [7], i.e., one of the most popular RTOS kernels for small-scale embedded systems, has more than 80 service calls. These services may 0-7803-9571-9/05/$20.00 2005 IEEE. 71

need to be fully utilized in order to write high-quality software. Therefore, it is easy to image that the quality of software automatically generated by these previous methods is lower than that of handcrafted RTOS-dependent software. In the design and validation methodology proposed in this paper, a designer first selects an RTOS and then describes system specification using service calls of the RTOS. Since the specification depends on a specific RTOS, it is not easy to reuse the specification to different RTOS platforms. To our experience, however, most of design teams in industry do not use a variety of RTOSs in practice. They tend to keep using a very limited set of RTOSs for several years in order to reuse existing software. Our methodology is suitable for such design teams or application fields where one or a very few RTOSs are used for a long period. Actually, we employ a standardized RTOS, i.e., µitron, to develop CAD tools (the cosimulation platform and the RTOS simulation model, etc.) to support our methodology. µitron is one of the most popular RTOSs in Japan for small- to middle-scale embedded systems. µitron is not a specific RTOS product, but is an application programming interface (API) standard. It only defines a set of API functions, and implementation of the function bodies may differ among µitron-basedrtoss.itisreportedin[7]that over 40% of RTOSs used in Japan are based on the µitron standard. Thus, our methodology is effective as long as a designer keeps using RTOSs which conform to the µitron standard. Note that our methodology itself is not limited to µitron-based RTOSs. Other RTOSs can be used if there exists a simulation model for the RTOSs. In [8] and [9], a different approach to embedded software design is presented where an application-specific RTOS and its simulation model are automatically generated. In their approach, application software is analyzed first, and then only the RTOS services used in the application are included in the final RTOS. The work is similar to ours in that a set of services which can be used in application software is pre-defined. The major difference is that their work puts a special focus on customizing an RTOS while our methodology is based on a standard RTOS. III. OUR COSIMULATION PLATFORM This section describes an overview of our cosimulation platform. A. Overview Fig. 1 shows the organization of our cosimulation platform which we have developed. RTOS Kernel Model supports a standardized RTOS specification named µitron. Application tasks are compiled and linked on a host computer so that they can be executed directly on the host in order to realize fast functional verification. Dedicated hardware and buses are described in SystemC and simulated with a SystemC simulation library. plays an important role in communication and synchronization between software and hardware. Application Application Application RTOS Kernel Model Fig. 1. Other Other Other Simulator Simulator Simulators (C++) SystemC Simulator Bus Model (SystemC) Our cosimulation platform Hardware Hardware Hardware Model (SystemC) Model (SystemC) Models (SystemC) Simulation Timer One of the remarkable features of our cosimulation platform is that a system designer can accurately describe hardware models using the SystemC language and also can accurately describe the concurrent behavior of application tasks by means of RTOS system calls. This feature enables very fast hardware/software cosimulation since both hardware and software are executed directly on the host computer. B. RTOS Kernel Model We have developed an RTOS kernel and its simulation model which completely support µitron 4.0 Standard Profile [10], [1]. The kernel model simulates the RTOS service calls such as context switching on an MS-Windows or Linux-based host computer. µitron is a standardized API of RTOSs for small- to middle-scale embedded systems. At present, the µitron specification is applied to a variety of embedded systems such as cellular phones, automotive controllers, and so on. Four profiles are defined in the µitron specification, i.e., Minimum- Set, Standard, Full-Set, andautomotive-control Profiles. Our RTOS and its simulation model conform to Standard Profile which has 81 API functions. µitron employs a priority based scheduling policy with at least 16 priority levels. In order for tasks to communicate and synchronize with each other, µitron provides semaphores, events, data queues, mailboxes, and so on. It also has several functions to handle interrupts for enabling, disabling, and masking them. More details on µitron can be found in [7]. In our cosimulation environment, each task is implemented as a thread on the host computer. The RTOS kernel model controls the threads based on their priorities. The RTOS kernel model is described in C/C++. Application tasks are described in C, linked with the RTOS kernel model, and then executed on the host computer. Unlike the SystemC simulator, the RTOS kernel model does not have a timer to count simulation cycles. Time ticks need to be provided to the 72

A. Sending read/write request HAL RTOS- I/F RTOS Kernel Model Hardware Bus Modules SystemC Simulator SystemC- I/F B. Sending interrupt request Hardware Modules Bus SystemC- I/F SystemC Simulator Interrupt Handlers Kernel RTOS- I/F RTOS Kernel Model Fig. 2. Communication mechanisms between hardware and software RTOS kernel model by a cosimulation platform or something else. The duration of time ticks is set to 1 millisecond or longer. Our previous cosimulator in [1] uses a timer on the host computer. However, it is difficult to synchronize the execution timing between software and hardware. On the other hand, the cosimulator presented in this paper obtains time ticks from the SystemC simulator in order to realize hardware/software synchronization. C. SystemC SystemC is a system-level design language standardized at OSCI (Open SystemC Initiative). SystemC is a relatively new language based on C++. Several constructs are introduced in order to easily describe concurrency, clocks, and synchronization with SystemC. In the past years, SystemC has been used mainly for simulation purposes. At present, several commercial tools for synthesizing SystemC are available. Our cosimulation platform uses an open SystemC simulator provided by OSCI. OSCI distributes this simulator in the form of a C++ library. User-designed modules are linked with the simulation library to generate a binary code directly executable on the host computer. D. manages communication between the RTOS kernel model and the SystemC simulator. It is also possible to communicate with functional hardware models in C/C++ and HDL simulators such as ModelSim from Mentor Graphics. Due to the flexibility of, more than one hardware simulator can be connected during cosimulation. For example, we can use two SystemC simulators and three HDL simulators at the same time. IV. MUNICATION AND SYNCHRONIZATION MECHANISMS This section describes mechanisms for communication and synchronization between the RTOS kernel model and the SystemC simulator. A. Communication Mechanism The RTOS kernel model can send read and write requests to hardware. On the other hand, hardware is able to generate interrupts to the RTOS kernel model. As shown in Fig. 1, these communications are passed through. Communication between and each simulator (i.e., the RTOS kernel model and the SystemC simulator) is implemented by means of the (Component Object Model) technology developed by Microsoft Corporation [11]. is an object-oriented interface technology which enables binary software components to interact with other software components in order to realize higher-level services. Communication between software and hardware is based on memory-mapped accesses. maintains a memory-map table. In order for a hardware simulator to take part in cosimulation, the simulator first requests Manger to register its address space into the table. Fig. 2-A describes a procedure that software sends a read/write request to hardware. When an application task needs 73

SystemC Simulator Simulation Timer User Defined Modules To RTOS Kernel Model Synchronization BUS SystemC I/F Fig. 3. Synchronization between SystemC and RTOS Kernel Model JPEG File VLD Dequantization IDCT YUV2RGB Decoded Image Display Fig. 4. A flow of the JPEG decoder to read data from or write to the hardware, the task calls a corresponding API function in the hardware abstraction layer (HAL). For example, a function sil reb mem(address) is called to read 1-byte data from a hardware module pointed by the address, and sil wrw mem(address, data) is used to write a word to a corresponding hardware module. The read/write request is stored into the queue. Then, RTOS- I/F retrieves the request from the queue and sends the request to through. When receives the request from RTOS Kernel Model, identifies a hardware simulator to which the given address is allocated by looking up the memorymap table. then dispatches the request to the hardware simulator. It should be noted that more than one hardware simulator can exist even though Fig. 2 assumes only a single SystemC simulator. In the SystemC simulator, a callback function in SystemC- I/F is invoked to put the request into the queue. In the SystemC simulator, there exists a thread named SystemC- I/F inside the (Bus Interface Unit) module. A callback function in the SystemC- I/F thread is invoked to receive the read/write request from and put it to the queue. Then, retrieves the request from the queue and generates a bus transaction according to the bus protocol in order to read data from or write data to the hardware module. In fact, for a write access, data to be written to the hardware is not passed from the RTOS kernel model to. Instead, a pointer to the data is passed. reads the data in the RTOS kernel model using the pointer and writes it to the hardware module. For a read access, similarly, reads the requested data from the hardware module and writes it to the RTOS kernel model using the passed pointer. Fig. 2-B shows mechanism for raising interrupts from hardware to software. This mechanism is similar to the one described above, but requests are transferred in the opposite direction. In RTOS Kernel Model, Kernel retrieves the interrupt request from the queue and invokes a corresponding interrupt handler. Note that not only a SystemC simulator but also some other simulators can be connected to if an interface to is equipped. At present, some commercial HDL simulators including ModelSim by Mentor [12] are connectable where a interface is implemented using FLI/PLI. Our cosimulation platform uses for communication between and simulators. However, other communication mechanisms can be used if RTOS- I/F and SystemC- I/F are replaced. For example, instead of, we can make use of the TCP/IP protocol so that we can easily implement distributed simulation. Our -based communication may impose larger performance overhead than SLDL-based RTOS modeling approaches such as [2], [3], [4]. In their approaches [2], [3], [4], the entire system including an RTOS, application programs and hardware is described in a single language such as SystemC or SpecC, leading to faster cosimulation. On the other hand, our -based cosimulation platform has greater flexibility at the cost of simulation speed. As explained above, various kinds of simulators or simulation models can be connected to our cosimulation platform, which enables multilingual cosimulation at various levels of abstraction. 74

RTOS Kernel Model SystemC [sec.] 200 182 Memory Processor Bus IDCT Module 150 100 113 Arbiter 50 46 VGA Hardware Model (C++) Shared Memory 0 C++ Model SystemC HDL Simulator Fig. 5. The hardware organization of the JPEG decoder Fig. 6. Simulation time (sec.) B. Synchronization Mechanism As described in Section 3.2, the RTOS kernel model does not have a timer to count simulation cycles. We have realized hardware/software synchronization by periodically sending time ticks from the SystemC simulator to the RTOS kernel model. Fig. 3 describes synchronization mechanisms in our cosimulation platform. Synchronization signals also are passed through and. The accuracy of execution timing between software and hardware largely depends on the period of time ticks. Our current implementation of the RTOS kernel model assumes that the minimum period is one millisecond. Therefore, our cosimulation platform does not allow cycle-accurate cosimulation, but still realizes fast cosimulation with a reasonable timing accuracy. V. DESIGN EXAMPLE This section evaluates our cosimulation environment through a case study with a JPEG decoder example. In this experiment, cosimulation is performed on a dual Xeon 2.4GHz processor system each with dual-threaded execution. Fig. 4 shows the flow of the JPEG decoder. A JFIF format file is given to the JPEG decoder as the input, and RGB data is generated. The decoder consists of four processes, i.e., VLD, Dequantization, IDCT, and YUV2RGB. Output data in the RGB format is displayed on a window on the host computer. Fig. 5 describes the hardware organization of the JPEG decoder system. The IDCT process was implemented in hardware and modeled in the SystemC language. In addition, a bus and a shared memory were described as SystemC modules. For comparison, we also developed functional and RTL models of IDCT. The functional model was written in C++ while the RTL model was in VHDL. We performed hardware/software cosimulation with each of the three IDCT models. Fig. 6 compares the cosimulation time among three cases. Cosimulation with SystemC is 38% faster than that with an HDL simulator. On the other hand, cosimulation with a C++ model is faster than that with SystemC by approximately 60%. This is mainly because of the difference in the abstraction level. The IDCT model in SystemC is bus cycle accurate while the C++ model is untimed. A screenshot of cosimulation with the SystemC model is shown in Fig. 7. We can verify both hardware and software at the same time using our cosimulation environment. VI. CONCLUSIONS RTOSs have become one of necessities in the design of complex systems. This paper has presented a cosimulation platform on which an RTOS kernel model, application tasks, and hardware models written in SystemC are simulated. Our cosimulation platform provides an RTOS kernel model which conforms to a standardized RTOS specification named ITRON. Application software which includes RTOS service call can be executed at high speed on a host computer. Hardware written in SystemC can also be executed on the host computer. The platform enables a system designer to efficiently co-validate hardware and software. In future, we plan to apply our cosimulation platform to a variety of applications. Improvement of timing accuracy is also one of our future work. ACKNOWLEDGMENTS This work was partially supported by JSPS Grant-in-Aid for Scientific Research (B) #17300014. REFERENCES [1] S. Honda, T. Wakabayashi, H. Tomiyama, and H. Takada, RTOS- Centric Hardware/Software Cosimulator for Embedded System Design, in Proc. of Int l Conf. on Hardware/Software Codesign and System Synthesis (CODES+ISSS), 2004. [2] D. Desmet, D. Verkest, and H. D. Man, Operating System Based Software Generation for Systems-on-Chip, in Proc. of Design Automation Conf. (DAC), 2000. [3] A. Gerstlauer, H. Yu, and D. Gajski, RTOS Modeling for System Level Design, in Proc. of Design Automation and Test in Europe (DATE), Embedded Software Forum, 2003. [4] H. Yu, A. Gerstlauer, and D. Gajski, RTOS Scheduling in Transaction Level Models, in Proc. of Int l Conf. on Hardware/Software Codesign and System Synthesis (CODES+ISSS), 2003. 75

RTOS Kernel Model SystemC Simulator VGA Model (C++) Fig. 7. Screenshot of cosimulation [5] F. Herrera, H. Posadas, P. Sanchez, and E. Villar, Systematic Embedded Software Generation from SystemC, in Proc. of Design Automation and Test in Europe (DATE), 2003. [6] H. Takada and K. Sakamura, µitron for Small-scale Embedded Systems, IEEE Micro, vol. 15, no. 6, 1995. [7] ITRON. [Online]. Available: http://www.assoc.tron.org/itron/ [8] L. Gauthier, S. Yoo, and A. A. Jerraya, Automatic Generation and Targeting of Application-specific Operating Systems and Embedded Systems Software, in Proc. of Design Automation and Test in Europe (DATE), 2001. [9] S. Yoo, G. Nicolescu, L. Gauthier, and A. A. Jerraya, Automatic Generation of Fast Timed Simulation Models for Operating Systems in SoC Design, in Proc. of Design Automation and Test in Europe (DATE), 2002. [10] TOPPERS Project. [Online]. Available: http://www.toppers.jp/ [11] Microsoft Corporation. [Online]. Available: http://www.microsoft.com/ [12] Mentor Graphics. [Online]. Available: http://www.mentor.com/ 76