SAHA: A Self-Adaptive Hardware-Software System Architecture for Ubiquitous Computing Applications

Transcription

1 SAHA: A Self-Adaptive Hardware-Software System Architecture for Ubiquitous Computing Applications Pao-Ann Hsiung and Chun-Hsian Huang Department of Computer Science and Information Engineering, National Chung Cheng University, Chiayi, Taiwan 621, ROC {pahsiung,huang}@cs.ccu.edu.tw Abstract Ubiquitous computing enables services and devices to be dynamically adapted to changing conditions. System adaptivity becomes a key requirement in providing possibly better system performance. Most existing ubiquitous computing systems either only support software adaptation or limit the usage of reconfigurable hardware designs as conventional hardware devices. As a result, system adaptation and performance are quite restricted. To provide a more robust system adaptation, we propose a self-adaptive hardware-software system architecture (SAHA) that consists of service suppliers, hardware adapter, system manager, observer, and reconfigurable hardware architecture. SAHA supports both hardware preemption and hardware virtualization within a complete self-aware system adaptation mechanism such that the utilization of system resources is enhanced and better performance is provided for ubiquitous computing applications. Experiments with a ubiquitous computing service for information encryption demonstrate that SAHA can reduce the turnaround time by at least 22.04% of that required by using the conventional method. Keywords: Dynamic Partial Reconfiguration, Hardware Virtualization, Hardware Preemption, Ubiquitous Computing 1. Introduction Ubiquitous computing provides human being with a more perfect life. Under natural interaction, ubiquitous computing enables information processing to be thoroughly integrated into everyday living, without being aware that it is doing so. In such a ubiquitous computing environment, not only services and devices can be dynamically adapted to changing environments, but contexts and preferences of users can be also switched seamlessly. To support dynamically changing and unpredictable ubiquitous computing applications, system adaptivity becomes a key requirement in providing better system performance. Most existing dynamic adaptive approaches to ubiquitous computing [1] [3] focus on adapting software services and applications, while hardware devices only passively support the changing software applications. In such a hardware architecture, hardware functions can be only configured once at design-time so that new hardware functions cannot be reconfigured at run-time, which leads to the inefficient use of hardware resources. Further, this restricts the adaptivity of ubiquitous computing system to changing environment conditions, and system performance is thus restricted by the underlying hardware. Though several research works [4], [5] have adopted the dynamic reconfiguration capability of FPGA [6] to support hardware adaptation, the hardware functions in these approaches [4], [5] are still managed as conventional hardware devices. This means that once the device node of a hardware function has been opened by a software application, the hardware function cannot be accessed by other software applications at the same time, though it is not always accessed by the software application that opens its device node. As a result, the utilization of reconfigurable hardware resources and the enhancement of system performance are still limited. To be able to not only adapt on-demand hardware/software functionalities but also provide better Quality-of-Service (QoS), ubiquitous computing applications require a more robust and effective infrastructure that can autonomously adapt its software and hardware functions to meet the dynamic requirements of various environmental situations. In this work, we try to solve the above adaptivity and performance problems in the current existing ubiquitous computing systems [1] [5] by proposing a Self-Adaptive Hardware-software system Architecture (SAHA). Figure 1 gives an example for illustrating the practicability of the proposed SAHA. In this ubiquitous computing environment, each family member can use his/her own electronic devices to monitor the house, watch the live television programs, and listen to the voice messages recorded in the home telephone via SAHA. To ensure the QoS and the information security, all data will be compressed, encrypted, or both in SAHA and then transferred to family members. Computing-intensive functions, such as Discrete Cosine Transform (DCT), cryptographic, and hash functions are implemented as hardware devices to provide better performance. Further, SAHA can adapt on-demand its hardware and software functionalities to different service requirements, based on the network services and electronic products used by family members. Figure 1 shows an ideal blueprint to apply SAHA to ubiquitous computing environments. However, it must solve several issues related to ubiquitous computing, including 1) how to make hardware functionalities adaptable? 2) how to

2 Crypt Hash HW2 HW2 Microprocessor SAHA Operating System DCT HW2 Crypt HW3 Hash HW1 Cryptographic HW1 DCT HW Internet Peripheral Controllers Fig. 1: Ubiquitous Computing Environment make hardware adaptation more efficient? 3) how can the utilization of hardware devices be maximized to serve more users? 4) when must hardware functionalities be adapted to different user requirements? To make hardware functionalities adaptable, the dynamic partial reconfiguration technology [6], [7] of FPGA devices is adopted in SAHA to perform computing-intensive functions. Hardware functions can be dynamically configured ondemand into the FPGA device, thus making the utilization of hardware logics in a FPGA device more efficient. To make hardware adaptation efficient, SAHA integrates our previously proposed hardware preemption technology [8], as a result of which high-priority hardware functions can interrupt low-priority hardware functions that have been configured in the FPGA. Thus, the utilization of hardware logic resources can be significantly enhanced. To maximize the utilization of hardware devices to serve more users, SAHA also integrates our previously proposed hardware virtualization technology [9], and thus a hardware device is virtualized such that it can be accessed by more than one user at the same time. To determine when the hardware functionalities must be adapted, SAHA provides a robust ubiquitous computing infrastructure. It includes service suppliers to interact with users, a hardware adapter to manage hardware functionalities on an FPGA device, an observer to be aware of the characteristics of user applications, and a system manager to manage all system adaptations. With the changes in environment conditions and user requirements, SAHA can effectively and autonomously adapt its hardware/software functions to support better performance. Our previous works [8], [9] have introduced the detailed designs of hardware preemption and virtualization mechanisms, respectively, and this work will focus on the design of SAHA for ubiquitous computing applications. The rest of the article is organized as follows. Section 2 discusses the related research works. Section 3 introduces the design of SAHA, while Section 4 introduces how the hardware virtualization and preemption techniques can be realized in SAHA to support system adaptation. The experimental evaluation and analyses are given in Section 5. Finally, Section 6 concludes this work. 2. Related Work Within a ubiquitous computing environment, computing devices are aware of changes in their environment, and thus they need to automatically adapt to environmental changes for satisfying user requirements. Odyssey [10] was a typical ubiquitous computing approach that supported applicationaware adaptation to adjust the quality of accessed data to match available resources. However, due to the lack of support for coordination between the adaptation policies, its notification approach may lead to inefficient solutions. To more efficiently support the capability of adaptation, Efstratious et al. [1] proposed an architecture that could support adaptive context-aware applications. However, a main constraint in the approach was that the infrastructure only notified applications about the environmental changes, and then application themselves needed to trigger the adaptive mechanism. Instead of the passive application adaptation, Ghim et al. [2] proposed a reflective approach to dynamic adaptation that could perform adaptation operation triggered by changes in the policy and context, while users and applications could trigger adaptation using policy documents. However, hardware functions in the existing research works [1], [2], [10] cannot be adapted to different requirements, which thus restricts system adaptation and performance

3 Memory Partial Bitstreams FPGA Memory Controller ICAP Network Controller Network Device em Bus Syst Microprocessor Unix-like OS PRR0 PRR1 PRR2 Service Supplier user space kernel space System Manager Hardware Adapter Service Supplier Observer Fig. 2: Self-Adaptive Hardware-Software System Architecture enhancement. To support hardware adaptation, Danek et al. [4] proposed self-adaptive networked entities (SANE) to build pervasive computing architectures. The SANE design included an observer to monitor computation process. Furthermore, a computing engine could be on-demand reconfigured as different hardware functions at runtime to adapt to different system requirements, by using the partial dynamic reconfiguration technology [6]. Lagger et al. [5] also proposed a self-reconfigurable pervasive platform for cryptographic applications. They compared a full-software design with a coprocessor design that had an FPGA device which could be partially configured with different cryptographic hardware cores. Compared to the former, the performance of the latter was significantly enhanced due to dynamic reconfiguration techniques. However, these existing approaches to hardware adaptation [4], [5] still managed reconfigurable hardware functions as conventional hardware devices. As a result, the enhancement of system performance using partial reconfiguration technology is still limited, which makes the utilization of reconfigurable hardware functions inefficient. In this work, SAHA provides a robust ubiquitous computing infrastructure that includes service suppliers, a hardware adapter, an observer, a system manager, a reconfigurable hardware architecture. Instead of focusing on only software adaptation [1], [2], [10], SAHA further supports hardware adaptation by adopting the partial reconfiguration technology. Different from the existing approaches to hardware adaptation [4], [5] that manage reconfigurable hardware functions as conventional hardware devices, SAHA integrates hardware preemption [8] and hardware virtualization [9] for providing more efficient system adaptation to changing ubiquitous computing applications. At the same time, system performance can be further enhanced through system adaptation. 3. Self-Adaptive Hardware-Software System Architecture To realize hardware adaptation, we implement the hardware architecture of SAHA in an FPGA device, instead of an ASIC device. In general, not all hardware functions are always accessed by the software applications. Using the FPGA devices, hardware functions can be configured on-demand at runtime, without integrating them into the system at design time. As a result, though the total amount of logic resources required by all hardware functions exceeds that available in the FPGA, SAHA can still support a larger number of hardware functions by using the capability of hardware adaptation. Furthermore, because a large part of computingintensive functions in the current SAHA implementation are cryptographic and hash functions, the parameter-specific architecture of the FPGA device also enables SAHA to provide better performance [11]. The SAHA design consists of a microprocessor, an FPGA device, a network device, and an off-chip memory, as shown in Figure 2. The hardware architecture of SAHA is implemented by using the Early Access Partial Reconfiguration (EA PR) design flow [6], in which several Partial Reconfigurable Regions (PRRs), such as PRR0, PRR1, and PRR2 as shown in Figure 2, are implemented in the FPGA. They can be dynamically reconfigured as different hardware functions to meet the requirements for different service suppliers. All reconfigurable hardware functions are encapsulated as partial bitstreams and stored in an off-chip memory. Further, the hardware architecture of SAHA contains an Internal Configuration Access Port (ICAP) controller to configure the partial bitstreams into the FPGA. The microprocessor runs a unix-like Operating System (OS) that includes service suppliers, a hardware adapter, a system manager, and an observer. Their detailed introductions are given in the following sections.

4 User Space Kernel Space Service Supplier 1 Service Supplier2 User Space Kernel Space Service Supplier 1 PRR1 PRR2 HW1 HW2 (a)logic Virtualization PRR1 PRR2 HW1 HW2 (b)hardware Device Virtualization Fig. 3: Hardware Virtualization Mechanism 3.1 Service Supplier The service supplier is a software application that interacts with a user, while it interacts with hardware functions for data capture and processing. Each service supplier has a priority, and thus the system manager can decide when it starts to serve its user, based on the current ubiquitous computing environmental conditions. Further, similar to the interactions between software applications and hardware devices in a conventional embedded OS, service suppliers in SAHA also interact with reconfigurable hardware functions through the device nodes. As a result, though SAHA supports system adaptation, the generality in accessing the hardware device design is still not sacrificed. Further, because all software and hardware adaptations in SAHA are performed underlying the kernel level, service suppliers can serve their users in a natural interaction method, without any adjustment in them. 3.2 Hardware Adapter The hardware adapter is used to manage the reconfigurable hardware architecture. When a service supplier requests a hardware function that is not configured in the FPGA, the hardware adapter thus loads the corresponding partial bitstream to the ICAP controller for configuring the required hardware function into the FPGA. The hardware adapter also records which hardware functions are now configured in the PRRs and which service suppliers are accessing them. As a result, the system manager can inquire about the information to estimate which system adaptation, such as hardware reconfiguration, hardware virtualization, and hardware preemption, is better for all ubiquitous computing applications. Further, the hardware adapter needs to support the system manager for performing the hardware preemption mechanism. The details of the hardware preemption mechanism in SAHA will be introduced in the next section. 3.3 System Manager The system manager is the core of SAHA that coordinates all system adaptations. It not only manages all data transfers within the SAHA design, but also supports the hardware virtualization and preemption techniques. Two types of hardware virtualizations, namely logic virtualization and hardware device virtualization, are supported by the system manager, as described in the following. 1) In the many-to-one logic virtualization as shown in Figure 3(a), a required hardware function (HW2) is virtualized such that it can be accessed by two service suppliers, Service Supplier 1 and Service Supplier 2, through the device nodes comm2 and comm3, respectively. Here, the data synchronization is controlled by the system manager. This many-to-one mapping between more than one service supplier and a configured hardware function increases the utilization of a hardware function. 2) In the hardware device virtualization as illustrated in Figure 3(b), the kernel module that is linked to and drives a specific hardware function (HW1) can be dynamically re-linked to another hardware function HW2. Without unnecessarily copying data between the user space and kernel space, the processing results of HW1 can be directly transferred to HW2 through the kernel module. This one-to-many mapping is a seamless reconfiguration of the underlying hardware, without any change to the software. Thus, using the hardware virtualization technique, multiple service suppliers can serve their users under the illusion of full access to the same reconfigurable hardware function through their own device nodes, while a service supplier can also access two or more reconfigurable hardware functions. Therefore, for changing ubiquitous computing environments, SAHA can adapt to more user requirements, while it can provide better performance. Though the partial reconfiguration technique enables parts of an FPGA device to be reconfigured as different hardware functions at runtime, the occupied logic resources of a configured hardware function can be released only after it finishes its execution. This would incur significant time overhead, and thus degrade system performance. However, for ubiquitous computing applications, the support for seamless services is very important. As a result, SAHA integrates the hardware preemption technique to further enhance the utilization of hardware logic resources per unit time. When the hardware preemption mechanism is triggered, the system manager requests the hardware adapter to send a swap-out

5 Request a HW function Does a PRR with the required ed HW function exist? NO Is the request from a NO service supplier with higher priority? Select another unused device node Link the unused device node to the required HW function NO YES Is the request from the same service supplier YES Link its previously used kernel module to the required HW function YES Request the hardware adapter to deliver the swap-out signal Wait until the swapout process finishes Reconfigure the required HW function Logic Virtualization HW Device Virtualization HW Preemption Fig. 4: Self-Aware System Adaptation signal to a hardware function that is being accessed by a service supplier with lower priority. After all the context data of the swap-out hardware function are saved in an offchip memory, the hardware adapter reconfigures the required hardware function into the corresponding PRR. Then, it notifies the system manager that the hardware function can be accessed. Here, the context data are the collections of the state registers and data registers. When the swap-out hardware function is reconfigured into the FPGA and all its context data are restored, it can continue execution from the state in which it was swapped out. As for the determination of when hardware virtualization and preemption mechanisms are used due to system adaptation, the system manager needs to collaborate with the observer. The detailed introduction will be given in the next section. 3.4 Observer Both the system manager and the hardware adapter provide the capability of system adaptivity for SAHA. As to when system adaptation is triggered, it mainly depends on the observer. Thus, the observer plays a key role to make SAHA self-aware to adapt to ubiquitous computing environments. The observer is aware of the characteristics of currently running applications. As shown in Figure 4, it collaborates with the system manager to decide which of the three proposed techniques, namely logic virtualization, hardware device virtualization, and hardware preemption. When a service supplier requests for a hardware function, the observer first asks the system manager whether the required hardware function has been configured in a PRR. If not, the observer determines what the priority level of the service supplier is, and then it queries the system manager whether the priority of this service supplier is higher than any service supplier that is accessing reconfigurable hardware functions. In our current implementation of SAHA, the priority levels of all service suppliers need to be preset during system initialization by users. Otherwise, SAHA is based on a first-come-first-served basis. If the service supplier does not have higher priority, it will wait until the required hardware function is configured into the FPGA. Otherwise, the hardware preemption mechanism is invoked, such that the system manager requests the hardware adapter to start the swap-out process. After the swap-out process finishes, the required hardware can be configured into the FPGA. Then, the observer continues to collaborate with the system manager to decide which hardware virtualization technique will be used. When the required hardware function is already configured, the observer checks whether the request is received from the same service supplier. If not, the system manager invokes the logic virtualization to dynamically link another unused device node to the required hardware function. Otherwise, the system manager invokes the hardware device virtualization to dynamically link the previously used kernel module to the PRR with the required hardware function, and thus the processing results of the previous hardware function can be directly transferred to the requested hardware function. Note that, using the hardware device virtualization, when a pair of device node and kernel module is linked to only one hardware function, the final processing results are thus transferred back to the service supplier. Through the cooperation between the service suppliers,

6 ioctl(devfp, 0, data); ioctl(devfp, 1, exp); ioctl(devfp, 2, mod); CB ioctl(devfp, 8, 0x ); ) ioctl(devfp, 8, 0x ); while( ioctl(devfp, 9, 0x )!= 1){}; result = ioctl(devfp, 10, 0x ); Com mm DTC HW SC Comm: Communication Interface Component; DTC: Data Transformation Component; CB: Context Buffer; SC: Swap Controller Fig. 5: Unified Communication Mechanism the hardware adapter, the system manager, and the observer, SAHA can provide a robust infrastructure that is capable of self-aware adaptation to ubiquitous computing applications. As to what types of ubiquitous computing applications are suited to SAHA, the related analysis will be given in Section Implementation of Hardware- Software Adaptation Besides the support of reconfigurable hardware architecture as introduced in Section 3, this section will introduce how the hardware virtualization and preemption techniques can be realized in SAHA to support system adaptation. To support the hardware virtualization mechanism, both the interfaces of device drivers and reconfigurable hardware functions in SAHA must be unified, such that service suppliers and reconfigurable hardware functions can be many-toone and one-to-many mapped. Therefore, we further propose a unified communication mechanism in SAHA to standardize the hardware/software communication interface, as shown in Figure 5. To minimize user design efforts, in our design environment, a user-designed hardware function can be integrated with a 3-tier interface, including (a) a partially reconfigurable (PR) template [12], (b) a reusable wrapper design, and (c) a communication interface component. The PR template consists of eight 32-bit input data signals, one 32-bit input control signal, four 32-bit output data signals, and one 32-bit output control signal. It also contains an optional Data Transformation Component (DTC) for unpacking incoming data and packing outgoing data based on the I/O registers sizes in the hardware functions, and a reusable wrapper design to support hardware preemption technique. The wrapper architecture in Figure 5 mainly consists of a context buffer (CB) to store context data and a swap controller (SC) to manage the swap-out and swap-in activities. Two types of reusable wrapper designs, namely Last Interruptible State Swap (LISS) wrapper and Next Interruptible State Swap (NISS) wrapper, are supported by SAHA, as described in the following. 1) The LISS wrapper stores the hardware context at each interruptible state, thus the hardware function can be swapped out from the last interruptible state whenever there is a swap request. It can be used for hardware functions whose context data size is less than that of the context buffer, as a result of which all context data can be stored in the context buffer using a single data transfer. 2) The NISS wrapper requires the hardware function to execute until the next interruptible state, store the context, and then swap out. It can be used when the context data size is larger than that of the context buffer, where the process of storing the context data into buffer and reading into memory is repeated and controlled by the hardware adapter. The communication interface component is used to connect the PR template to the system bus. Further, the processing results can be buffered in the communication interface component until the service supplier reads them. Within the software part, different from the traditional device driver designed for a specific hardware function, a unified kernel module is designed to only interact with the fourteen 32-bit signals of the PR template. All the interactions between service suppliers and reconfigurable hardware functions are through the ioctl system calls of the unified kernel module and implemented in a hardware control library. Thus, a new user-designed hardware function needs to be only integrated with a PR template and included its control methods into the hardware control library. As a result, SAHA can be easily extended to support more types of ubiquitous computing applications, without being only restricted to our current implemented applications.

7 PRR1 PRR2 MicroBlaze ICAP Fig. 6: FPGA Implementation Finish Time (ms) x 10 8 Conventional Logic Virtualization x 10 5 # of shared HW functions # of iterations for the previous application Fig. 7: Logic Virtualization and Conventional Method 5. Experimental Evaluation The current SAHA design was implemented on the Xilinx ML310 platform [13] with a Virtex II Pro FPGA device, in which the PetaLinux embedded OS [14] ran on a Xilinx MicroBlaze soft-core processor [15] as shown in Figure 6. Due to the resource limitations of our current implementation, only a large PRR1 and a small PRR2 are implemented in the FPGA. In this section, we will first analyze the hardware virtualization and preemption techniques in SAHA, and then give a case study that SAHA itself adapts to ubiquitous computing applications using both hardware preemption and hardware virtualization. 5.1 Performance Analysis In the following sections, we will discuss the impact on system performance, respectively, using hardware virtualization and hardware preemption Hardware Virtualization To analyze the impact on system performance using hardware virtualization in SAHA, we first measure the time required for each of the following basic operations. The average amounts of time to insert a kernel module, to open a device node and to close it are 830, 0.253, and milliseconds, respectively. The average amounts of time to write a 32-bit data to and to read a 32-bit data from the kernel space are and milliseconds, respectively. The average computing time for processing a pixel image using the RSA32, RSA64, RSA128, RC6, CRC32, CRC64, and CRC128 hardware functions is milliseconds, while the average time to read a 32- bit data from a hardware function and then write it to another hardware function through the unified kernel module is milliseconds. As introduced in Section 3.3, through logic virtualization, a service supplier can access a hardware function that has been accessed by another previous service supplier, as long as the previous service supplier is not using it, irrespective of whether it is released or not. Without logic virtualization, the hardware function cannot be accessed until the previous service supplier releases it. Thus, using the conventional method in the best case, the waiting time would be equal to the total processing time of the shared hardware functions in the previous service supplier. Based on our measurement of the time required by each basic operation, Figure 7 compares logic virtualization and the conventional access method by looking at the finish time of a service supplier that has some hardware functions previously accessed by another service supplier. Here, the numbers of shared hardware functions and iterations to access the shared hardware functions in the previous service supplier are set ranging from 0 to 1, 000 and from 0 to 1, 000, 000, respectively. We can observe that the time required by using the logic virtualization becomes lesser and lesser compared to the time required by using the conventional access method, when the numbers of shared hardware functions and iterations to access the shared hardware functions in the previous service supplier gradually increases. This is because logic virtualization reduces significantly the waiting time for the shared hardware functions. Thus, performance improvement using the logic virtualization becomes more and more prominent with an increase in the total processing time of shared hardware functions in the previous service supplier. Using hardware device virtualization, the processing results (data) of a hardware function can be directly transferred to another hardware function through the unified kernel module. Thus, hardware device virtualization is used to save time by avoiding repeated data transfers between the OS

8 Conventional HW Device Virtualization The total processing time (ms) x x # of HW functions 5 # of iterations 10 x 10 4 Fig. 8: HW Device Virtualization and Conventional Method kernel and the user level. Based on our measurement of the time required by each basic operation, Figure 8 shows the total processing time of a service supplier using the hardware device virtualization technique and the conventional method. Here, the number of hardware functions to be sequentially accessed by the service supplier and the number of iterations to access the hardware functions are both set ranging from 0 to 100, 000. We can observe that the time required by using the hardware device virtualization technique becomes lesser and lesser compared to the time required by using the conventional method, when the numbers of hardware functions and iterations to access the hardware functions gradually increase. From the above results, we can clearly observe that the hardware virtualization technique allows greater performance improvement, compared to the conventional method, when a service supplier requires more and more iterations to access hardware functions. This also shows that the hardware virtualization technique will play a key role to help system adaptation and provide better performance, especially for ubiquitous computing applications, such as multimedia applications and the cryptographic applications, that usually must process a larger amount of information and data Hardware Preemption In our current implementation, the software processing time is much more than the hardware processing time. To clearly show the contribution to hardware preemption in SAHA, we directly compared it with another reconfiguration-based method (RBM) [16]. Here, RBM requires readback support from the reconfigurable logic such as state extraction from the readback stream and manipulation of the bitstreams for context restoring. Figure 9 shows the time overheads in swapping out and 40.4% 40.9% Fig. 9: Experiments on Hardware Preemption swapping in for the LED controller, the Greatest Common Divisor (GCD), the Data Encryption Standard (DES), and DCT hardware functions. We can observe that the hardware preemption mechanism in SAHA performs better than RBM. For the more complex DES and DCT hardware functions, our method can reduce the swap time by 40.4% and 40.9%, respectively, of that required by RBM. We are thus saving much time, which is very important for supporting seamless ubiquitous computing services. Even though additional reconfiguration time is required, the hardware preemption mechanism in SAHA would enable more service suppliers to adapt to changing environmental conditions and achieve higher system performance. 5.2 Case Study using both HW Preemption and Virtualization The impacts on performance using the hardware preemption technique and the hardware virtualization technique have been discussed in Section 5.1. In this case study, SAHA will serve two ubiquitous computing applications, including a monitoring service and a live television service. Note that this experiment does not use the stream buffering technology and mainly shows performance improvement in SAHA, and thus the amounts of time to capture data from the peripherals and transfer data to users on the network are omitted. As shown in Figure 10, the live television service requests for processing fifty images using the RC6 and CRC32 hardware functions. However, the DCT and CRC32 hardware functions are now configured in PRR1 and PRR2, respectively, where the DCT function required by the lowpriority monitoring service has already executed for 55,000 ms and PRR1 is selected to configure the required RC6 function. Without the hardware preemption technique, the RC6 hardware function will be configured in PRR1 only after the DCT function finishes. According to our experimental results, it needs 13,122.8 ms exclusive of the previous execution time of 55,000 ms to finish the current DCT execution and 177 ms to configure the RC6 function. Note

9 RC6 HP LV PRR1 DCT HDV PRR2 CRC32 Priority: Live TV Service > Monitoring Service HP: Hardware Preemption; LV: Logic Virtualization; HDV: Hardware Device Virtualization; Fig. 10: Case Study using both Hardware Preemption and Virtualization Table 1: Comparison on Processing Time Case System Adaptation Preemption Virtualization Time (sec) Improvement A No No B Yes No % C No Yes % D Yes Yes % that here we assume that the current monitoring service (with requirement for the DCT hardware function) can also be preempted after one DCT execution. If this is not the case, a much greater delay will be incurred without the hardware and software preemption. However, using the hardware preemption technique, it needs only ms for the NISS wrapper or ms for the LISS wrapper to swap out the DCT function, and 177 ms to configure the RC6 function. After hardware and software preemption, the required RC6 hardware function is configured into PRR1. Using the conventional method, the live television service must now wait until the currently executing monitoring service closes the device node comm1 that is linked to PRR1, and then the live television service opens the same device node comm1 to access PRR1 with the RC6 hardware function. However, using the logic virtualization, another pair comm2 of device node and kernel module can be simultaneously used to connect to PRR1 and the live television service starts accessing PRR1 with the RC6 hardware function more quickly. The time saved by not waiting for another monitoring service to close and open the device node comm1, namely logic virtualization, is around seconds according to our experimental results. Finally, using the hardware device virtualization, the processing results (output data) of the RC6 hardware function in PRR1 can be directly transferred to the CRC32 hardware function in PRR2 through the kernel module in the pair comm2 of device node and kernel module without going back and forth between the OS kernel and the user levels, as introduced in Section 3.3. Table 1 gives the total processing time required for finishing the live television service, where Cases A, B, C, and D represent the four scenarios that either use or do not use hardware preemption, and/or hardware virtualization. Case A is the conventional method in a Unixlike embedded system, thus it is taken as the baseline method. The fifth column of Table 1 shows the percentage of performance improvement compared to the baseline method Case A. We can observe that system performance can be significantly enhanced, when hardware preemption (Case B) or hardware virtualization (Case C) is used. Here, the performance improvement using hardware preemption results from the configuration of RC6 without waiting until the monitoring service completes the compression of an image. Thus, more improvements can be achieved with hardware preemption, when SAHA receives the request for preempting the DCT hardware function earlier. Employing both hardware preemption and hardware virtualization (Case D), SAHA can reduce the processing time by around 22.04% of that required by using the conventional method. As a result, system adaptation in SAHA can provide not only seamless service but also more efficient infrastructure support for the services in embedded and ubiquitous applications. 6. Conclusion To provide a more robust ubiquitous computing infrastructure, we propose a self-adaptive hardware-software system architecture (SAHA) that solves the issues related to system adaptation, as described in Section 1. SAHA also integrates the hardware preemption and virtualization techniques and has a complete self-aware system adaptation mechanism to provide better performance for ubiquitous computing applications. Our experimental results also demonstrate that not only system resources can be effectively utilized, but system performance can be also improved significantly, when ubiquitous computing applications are served by SAHA. References [1] C. Efstratiou, K. Cheverst, N. Davices, and A. Friday, An Architecture for the Effective Support of Adaptive Context-Aware Applications, in Proc. of the 2nd International Conference on Mobile Data Management (MDM 2001). Springer, January 2001, pp [2] S.-J. Ghim, Y.-I. Yoon, and J.-W. Choe, A Reflective Approach to Dynamic Adaptation in Ubiquitous Computing Environment, in Proc. of the International Conference on Networking Technologies for Broadband and Mobile Networks (ICOIN 2004). Springer, February 2004, pp [3] J.-Z. Sun, Adaptive Determination of Data Granularity for QoS- Constraint Data Gathering in Wireless Sensor Networks, in Proc. of the 2009 Symposia and Workshops on Ubiquitous, Autonomic and Trusted Computing (UIC-ATC 2009). IEEE Computer Society, June 2009, pp [4] M. Danek, J.-M. Philippe, P. Honzik, C. Gamrat, and R. Bartosinski, Self-Adaptive Networked Entities for Building Pervasive Computing Architectures, in Proc. of the 8th International Conference on Evolvable Systems: From Biology to Hardware (ICES 2008). Springer, September 2008, pp

10 [5] A. Lagger, A. Upegui, E. Sanchez, and I. Gonzalez, Self- Reconfigurable Pervasive Platform for Cryptographic Application, in Proc. of the 16th IEEE International Conference on Field Programmable Logic and Applications (FPL06). IEEE CS Press, August 2006, pp [6] Xilinx, Early Access Partial Reconfiguration User Guide, UG208, [7] P.-A. Hsiung, M. D. Santambrogio, and C.-H. Huang, Reconfigurable System Design and Verification. CRC Press, USA, ISBN: , [8] C.-H. Huang and P.-A. Hsiung, Software-Controlled Dynamically Swappable Hardware Design in Partially Reconfigurable Systems, EURASIP Journal on Embedded System, vol. 2008, article ID , 11 pages, doi: /2008/ [9], Hardware Resource Virtualization for Dynamically Partially Reconfigurable Systems, IEEE Embedded Systems Letters, vol. 1, no. 1, pp , May [10] B. Noble, System Support for Mobile, Adaptive Applications, IEEE Personal Communications, vol. 7, no. 1, pp , February [11] T. Wollinger and C. Paar, How Secure are FPGAs in Cryptographic Applications, in Proc. of the 13th IEEE International Conference on Field Programmable Logic and Applications (FPL 03). Springer Verlag, September 2003, pp [12] C.-H. Huang, P.-A. Hsiung, and J.-S. Shen, UML-based hardware/software co-design platform for dynamically partially reconfigurable network security systems, Journal of Systems Architecture (JSA), vol. 56, no. 2-3, pp , February 2010, (doi: /j.sysarc ). [13] Xilinx, ML310 User Guide, [14] PetaLogix, PetaLinux, [15] Xilinx, MicroBlaze Processor Reference Guide, Embedded Development Kit, EDK 8.2i - UG081 (v6.3), August [16] H. Kalte and M. Porrmann, Context Saving and Restoring for Multitasking in Reconfigurable Systems, in Proc. of the 15th IEEE International Conference on Field Programmable Logic and Applications (FPL 05). IEEE CS Press, August 2005, pp