SEOS: Hardware Implementation of Real-Time Operating System for Adaptability

Size: px

Start display at page:

Download "SEOS: Hardware Implementation of Real-Time Operating System for Adaptability"

Kelly Bishop
5 years ago
Views:

1 2013 First International Symposium on Computing and Networking SEOS: Hardware Implementation of Real-Time Operating System for Adaptability Soon Ee Ong, Siaw Chen Lee IC Design Engineering Altera Corporation (M) Sdn Bhd Bayan Lepas, Penang, MY Noohul Basheer Zain Ali, Fawnizu Azmadi B Hussin Dept. of Electrical and Electronics Universiti Teknologi Petronas Tronoh, Perak, MY noohul.z@petronas.com.my, fawnizu@petronas.com.my Abstract Real-Time Operating System (RTOS) is widely used in real time embedded system for computing resource management. It is commonly implemented as fundamental layer in software framework. However, RTOS inevitably causes extra overhead and latency to the system. One of the innovative approaches to improve the overhead and latency is to bring the RTOS out from software framework and implement as hardware component. For past decades, researches had proved that significant performance improvement can be achieved by implementing RTOS in hardware. However, these research outcomes failed to get wide acceptance in commercial products. We postulate that the lacking of interest in commercial community on hardware approached RTOS is due its high level of difficulty in adaptation process. Adapting hardware based RTOS in embedded system requires in depth knowledge on operating system as well as significant amount of manpower resources. This makes the hardware RTOS unpopular despite of the performance offered. This paper proposed a Simple and Effective hardware based Real-Time Operating System (SEOS) designed to provide high adaptability for ease of hardware RTOS adaptation, at the same time significantly improved the performance. Experimental result shows that SEOS has great performance advantages over software based RTOS. Keywords-Real-time Operating System; RTOS; Hardware RTOS; Adaptability; SEOS; I. INTRODUCTION RTOS is commonly implemented in software framework of embedded systems. The extra computing power and memory resources consumed by RTOS caused overhead and latency on the system, thus indirectly affects the system performance [2]. Over the years, researchers were exploring the technical feasibility as well as benefits on the hardening of RTOS components [4] [8]. These hard works had promised us with significant system performance improvement through hardening of varies RTOS components. However, hardware implemented RTOS fails to gain enough popularity in commercial community. Most of these hardened RTOS solutions are sophisticated in nature and requires in-depth knowledge on RTOS to implement. Thus, we postulate that the lacking of embedded system engineers whom are familiar with hardware implementation of RTOS has limited the market popularity on hardware based RTOS solution. Motivated by the aim to provide an easily adapted yet performance improved hardware RTOS architecture, we developed a simple and effective hardware implemented RTOS, namely SEOS, that is highly adaptable. Section II briefly introduces the related works in the field of hardware RTOS and Section III explains the architecture of SEOS. The adaptability aspect of SEOS is discussed in Section IV. Section V compares different RTOS solutions in adaptability aspect while Section VI tells about test setup and results on performance comparison. Finally, Section VII concludes the paper. II. RELATED WORK In 1995, T. Nakano and his colleagues hardened system call scheduler of RTOS, named silicon TRON [3], [4]. Silicon TRON works together with the rest of system call functions and application interface processes coded in software (μitron) to form a complete RTOS, Silicon OS. Few years later, V. Mooney and his colleagues presented the hardened δ framework [5] that aims to assist the software RTOS, Atalanta [13] in speed acceleration and error prevention. Both Silicon OS and δ framework consists of customized hardware and software part of RTOS. L. Lindh and F. Stanischewski on the other hand developed a real-time microkernel in hardware, named Real-Time Unit (RTU) [6], [7], [11]. RTU is implemented in co-processor level for performance improvement and deterministic purposes. P. Kohout et al. also presented a processor extension design, named Real-Time Task Manager (RTM) that handles scheduling, time management and event management in hardware [8]. Both mentioned solutions proposed the offloading of RTOS core functionalities as hardware microkernel in order to lower the system overhead and improve the response time, while maintaining majority of RTOS functions running in a simplified version of commercial software RTOS. Andrew et al. further suggested moving a portion of heavy duty or critical tasks from application software into hardware [9], [10]. In short, all proposals above achieved system performance improvement from the benefit of having partial RTOS functionalities and application software tasks transferred into hardware to ease the computing and memory resources of embedded processor. However, this complicates the RTOS adaptation process. Hardware- Unrecognized /13 Copyright $31.00 Information 2013 IEEE DOI /CANDAR

Figure 2. Architecture Comparison Figure 1. SEOS Top Level Functional Block Diagram Figure 3.

their respective professional areas but not in the detail architecture design of RTOS. This creates requirement for additional member which incurs addition cost and project management complexity.

later stage which will impact product s time-to-market. Also, the design from a predecessor products may not be easily ported over. III.

2 Figure 2. Architecture Comparison Figure 1. SEOS Top Level Functional Block Diagram Figure 3. Context Switch Pseudo Code software co-existed RTOS porting process requires in depth knowledge on RTOS architecture to succeed the adaptation while embedded system engineer normally specialized in their respective professional areas but not in the detail architecture design of RTOS. This creates requirement for additional member which incurs addition cost and project management complexity. Furthermore, complex solutions such as Hybrid Thread Programming Model [9] requires careful hardware-software boundary planning in the beginning stage of project cycle to avoid overhaul redesign in later stage which will impact product s time-to-market. Also, the design from a predecessor products may not be easily ported over. III. SEOS ARCHITECTURE This section is to give a top level overview of the proposed SEOS architecture. Details architecture implementation of SEOS shall be covered in a separate paper, as this paper focus on the adaptability aspect of SEOS. SEOS is implemented in Verilog Hardware Description Language (Verilog HDL). It can be employed in System-On-Chip (SoC) or Field-Programmable Gate Array (FPGA) platform. Similar to any other IP modules, SEOS is instantiated as one of the Intellectual Property (IP) module that hook on to system interconnect bus. The top level functional block diagram of SEOS is shown in Figure 1. The Scheduler is a priority-based pre-emptive (rate-monotonic) kernel that responsible for tasks management scheduling. A 64-bit programmable countdown timer is in place for use by task scheduler and can also be used by application software as general timer. ICS provides the mechanism for intertask synchronization (Semaphore and Mutex) and inter-task communication (Mailbox and Queue). IB is a protocol dependent slave port bridge that provides SEOS the connection to system interconnect for command and data read/write operations. It can be configured to any types of interconnect, namely Avalon, Advanced Extensible Interface (AXI) and Wishbone. GBI is interconnect type independent module that handle commands and data to/from processor via IB. IV. ADAPTABILITY ASPECT OF SEOS Triggered by more rigorous performance requirements on modern embedded systems, it is of natural attempt that researchers will try to push some RTOS components into hardware for performance boosting. All reviewed hardware RTOS solutions retain software based components and use hardware components as companion for performance acceleration. SEOS initiates a different approach to improve adaptability. All major OS functionalities are shifted into hardware, retaining only simple API and macros for interfacing purpose. Figure 2 illustrates the differences between reviewed hardware RTOS versus SEOS architecture. A. Simplified Hardware-Software Interface SEOS uses direct register mapped Application Programming Interface (API) and Context Switch Macro (CSM) for application software to interface with SEOS as shown in Figure 2. API and CSM are placed in two reference code files for on-field customization. seos.h header file defines the register mapping address offset and definition of API, while seos.asm contains customizable reference assembly code for CSM. With these API set, porting of application software among SEOS can be done by simply adjusting the SEOS BASE offset address according to system bus assignment. Figure 3 demonstrates the pseudo code of context switch macro in seos.asm. B. Configurable Interconnect Bus Interface All SEOS hardware parameters in seos.v are made to be configurable. The type of IB can be configured to match the system interconnect type by using define directive in the seos.v file. Current supported IB types are Altera Avalon,

3 Table I FPGA RESOURCE UTILIZATION Build Task Semaphore Mailbox LE Counts Embedded Counts Memory Block (bits) , , ,385 03, ,514 6,144 Figure 5. SEOS Adaptation Process Figure 4. μc/os-ii Adaptation Process A. μc/os-ii Adaptation Process Figure 4 explains the porting process for μc/os-ii software RTOS. This adaptation process concentrates on the customization of below 3 files, (1) OS CPU.h for macro to enter and exit critical section, (2) Ten C functions in OS CPU.c for tasks management, and (3) Four assembly functions in OS CPU.asm for context switch and interrupt routine [1]. and Advanced extensible Interface (AXI). More IB type will be supported along with the maturity of SEOS. C. Compact and Configurable Hardware Size SEOS opts to have its resources configurable and compact in size. The numbers of task, semaphores and mailbox can be configured to any sizes in SEOS. SEOS resources are created during the compilation and its hardware size is determined by the number of resources created. Table I shows example of FPGA resource utilization based on Logic Element (LE) counts and Embedded Memory Block (EMB) bits for different SEOS configurations. For larger resource usage, SEOS further optimize it with embedded memory block for more compact silicon footprint. D. Standardized OS Porting Procedure SEOS provides high degree of abstraction in the adaptation process. No in depth knowledge on RTOS internal mechanism or the details of SEOS architecture is required to carry out the implementation of SEOS. Adaptation can be completed by simply following the generic guideline provided. The detail steps of adaptation are described in Section V. V. ADAPTABILITY COMPARISON In this section, the OS adaptation process of μc/os-ii, proposed SEOS, RTU, and δ framework is compared with the help of flow chart illustration. B. SEOS Adaptation Process SEOS adaptation process consists of two categories, one on hardware and another on software, as shows in Figure 5. The following are the general steps for SEOS software adaptation: 1) Includes seos.h header file. Defines base offset address and system bus width. 2) Includes and customizes seos.asm assembly file for context switch handling. The following are the general steps for SEOS hardware adaptation: 1) Defines the parameter of resources size and IB type in seos.v file. 2) Instantiates SEOS module and connects its system interconnect bus to IB slave port in embedded system hardware platform. Timer output interrupt should also be connected to processors interrupt port. C. RTU Adaptation Process RTU proposed by L. Lindh [12] is a hardware microkernel designed to replace the core functionality of software RTOS. Figure 6 shows the adaptation process on example of adapting RTU into μc/os-ii platform. In software adaptation process, the software RTOS source code needs to be modified to remove those core functionalities that will be handled by hardware RTU, such as task management, time management, semaphore and flag management. after that, OS CPU.h, OS CPU.c and OS CPU.asm shall also be modified similar to the porting process of μc/os-ii

4 Figure 6. RTU Adaptation Process The best option on hardware-software distribution can be hard to determine with no reference on prior performance data. After the allocation, δ framework GUI automation software tool is used to configure and generate the software C header files and hardware verilog files. In software adapting process, the generated makefile and C header files need to be customized and merged into the software RTOS source code. The modified RTOS will then go through similar software adapting process as describes in μc/os-ii. For hardware adaptation process, the generated Verilog file is customized and then connected to the system interconnect bus for system integration. Figure 7 illustrates the mentioned adapting process of δ framework. In summary, μc/os-ii as software RTOS has the simplest adapting process, while RTU and δ framework are relatively complicated in the adapting process. It s clearly shown that hardware RTOS solutions need major modifications. SEOS on the other hand imposes simpler adaptation process. This is mainly resulted by the hardware centric, simplified interface approaches and configurability nature of SEOS. A. Test Platform VI. TEST SETUP AND RESULT A test platform is setup to compare the performance between proposed SEOS and software RTOS, the μc/os- II, to ensure SEOS have the performance advantage. An Altera Cyclone-II FPGA development board with NIOS-II soft core processor, flash memory, SDRAM and I/O module is used as test platform development. Avalon interconnect bus is used as system interconnect. The test is separated into two sections. First section measure the performance of SEOS and second section replace SEOS with μc/os-ii. Figure 7. δ Framework Adaptation Process as describes earlier. In hardware adaptation process, the interconnect bridge hardware and resources size need to be developed and customized in RTU verilog code based on the targeted embedded system platform requirements. RTU will then needs to be hooked up to the interconnect bus for system integration. D. δ framework Adaptation Process δ framework is a hybrid RTOS solution. The adaptation of δ framework starts as early as system level design definition phase. The portion of RTOS that needs to be implemented in hardware has to be identified in advanced. B. Test Cases Three test cases are designed to measure the following four performance parameters for both sections. Computing Process Overhead: A task loop is created with a fixed number of benchmarking tasks. Fixed iterations of loop are executed for both test sections. Total time taken to execute the loops is measured. The percentage of computing process overhead reduction can be calculated by comparing the difference in total computing time for both RTOS solutions. Task Level Interrupt Latency: An external interrupt source is setup to trigger an interrupt service routine randomly. The interrupt service routine is coded to post a semaphore, in which will cause context switch to switch to the task that handles this external interrupt event. Upon receiving of the semaphore, the task will force a GPIO pin to high. Time latency is measured at the point when external interrupt get triggered to the point when task trigger the said GPIO

5 Table II PERFORMANCE COMPARISON RESULT Measurement Computing Process Time ( μs) Performance Parameter SEOS μc/os-ii Improvement Computing Time 13,405,265 19,608, % (loops) Task Level % Interrypt Latency Inter-task Comm % and Sync. Latency Intertask Communication & Synchornization Latency: Two tasks are created in this test setup, whereby one task will post a semaphore while the other task is pending to receive the semaphore. Latency is measured for time taken between the posting and receiving of the semaphore. Performance Data Jitter: Performance jitter for the above three parameters is computed by calculating the variance of data sets collected. C. Result Table II denotes the comparison of the three measured parameters. SEOS has lower system overhead which indicated by 31.6% less computing time compares to μc/os-ii. The computing time saving is mainly contributed by the offloading of kernel scheduling work to SEOS hardware. Besides, the data access time to SEOS register is also shorter compares to SDRAM during context switching. The task level latency of SEOS reduces in an average of 83.5% compares to μc/os-ii. As for intertask communication and synchronization latency, SEOS is 71.9% lower than μc/os- II. The variance of performance data in computing overhead and latencies determined the jitter of timing consistency that is also critical for RTOS performance. From the collected data, calculated jitter shows reduction of task level interrupt latency from % to 1.59%, while compuring overhead drops from % to %. It is proven that SEOS has much smaller performance data jitter as compares to μc/os-ii. VII. CONCLUSION This paper presented a hardware implemented Real Time Operating System, namely SEOS, which is architected for high adaptability and superior performance. The work of this paper is motivated by the intention to create a hardware RTOS that will be welcomed by commercial community. SEOS core functionality can be further enhanced by adding master interconnects port to enable memory management capability. Furthermore, the incorporation of system level functionalities like network connectivity, file system, and USB serial interface can also help to ease the system development efforts as well as shorten the time-to-market of embedded products. REFERENCES [1] J. Labrosse, MicroC/OS-II: The Real-Time Kernel. R&D Books, Lawrence, KS, [2] P. Laplante, S. Ovaska, Real-Time System Design and Analysis: Tools for Practitioner. Wiley-IEEE Press, [3] T. Nakano, A. Utama, M. Itabashi, A. Shiomi and M.Imai, Hardware Implementation of a Real-time Operating System, In Proceedings of the Twelfth TRON Project International Symposium, IEEE Computer Society Press, pp , Nov [4] T. Nakano, Y. Komatsudaira, A. Shiomi and M. Imai, VLSI Implementation of a Real-time Operating System, In Proceedings of ASPDAC 97, pp , January, [5] B. S. Akgul, J. Lee and V. Mooney, System-on-a-Chip processor synchronization hardware unit with task preemption support, International Conference on Compilers, Architecture and Synthesis for Embedded Systems (CASES 01), pp , November [6] L. Lindh, and F. Stanischewski, FASTCHART A Fast Time Deterministic CPU and Hardware Based Real-Time-Kernel, In Proceeding of IEEE Euromicro workshop on Real-Time Systems, June [7] J. Mooney III, J. Lee, A. Daleby, K. Instrom, T. Klevin, L. Lindh, A comparison of the RTU Hardware RTOS with a Hardware/Software RTOS, In Proceedings of the 2003 Asia and South Pacific Design Automation Conference, pp , [8] P. Kohout, B. Ganesh and B. Jacob, Hardware Support for Real-Time Operating Systems, In Proceedings of the Conference on Hardware/Software codesign and system synthesis of contents, p.45-51, Newport Beach, USA, [9] D. Andrews, W. Peck, J. Agron, K. Preston, E. Komp, M. Finley, R. Sass, Hthreads: A Hardware/Software Co-Designed Multithreaded RTOS Kernel,, In Proceeding of the 10th IEEE Conference on Emerging Technologies and Factory Automation (ETFA 2005), vol.2, pp.8, Sept [10] W. Peck, E. Anderson, J. Agron, J. Stevens, F. Baijot, D. Andrews, Hthreads: A Computational Model for Reconfigurable Devices, In Proceedings of the International Conference on Field Programmable Logic and Applications (FPL 2006), pp.1-4, Aug [11] S. Nordstrom, L. Lindh, L. Johansson, T. Skoglund, Application specific real-time microkernel in hardware,, In Proceeding of the Real Time Conference, 14th IEEE-NPSS, [12] Adomat, Joakim, Johan Furunas, Lennart Lindh, and Johan Starner, Real-time kernel in hardware RTU: a step towards deterministic and high-performance real-time systems, In Real-Time Systems, 1996., Proceedings of the Eighth Euromicro Workshop on, pp IEEE, [13] Mooney III, Vincent J., and Douglas M. Blough, A hardware-software real-time operating system framework for SoCs, Design & Test of Computers, IEEE 19.6 (2002):

A hardware operating system kernel for multi-processor systems

A hardware operating system kernel for multi-processor systems Sanggyu Park a), Do-sun Hong, and Soo-Ik Chae School of EECS, Seoul National University, Building 104 1, Seoul National University, Gwanakgu,