DOMAIN PARTITIONING TECHNOLOGY PROCESSORS FOR EMBEDDED MULTICORE. ...In embedded systems, application

Transcription

1 ... DOMAIN PARTITIONING TECHNOLOGY FOR EMBEDDED MULTICORE PROCESSORS... TODAY S EMBEDDED SYSTEMS REQUIRE BOTH REAL-TIME CONTROL FUNCTIONS AND IT FUNCTIONS. INTEGRATING MULTIPLE OPERATING SYSTEMS ON A MULTICORE PROCESSOR IS ONE WAY TO MEET THESE REQUIREMENTS. HOWEVER, IN THIS APPROACH, ONE OPERATING SYSTEM S FAILURE CAN BRING DOWN THE OTHER OPERATING SYSTEMS. TO ADDRESS THIS ISSUE, THE AUTHORS PROPOSE A MULTIDOMAIN EMBEDDED SYSTEM ARCHITECTURE WITH A PHYSICAL PARTITIONING CONTROLLER....In embedded systems, application fields are rapidly expanding and their functionality and complexity are dramatically increasing. 1 Today s embedded systems require not only the real-time control functions of traditional embedded systems but also IT functions, such as multimedia computing, multiband network connectivity, and extensive processing for database transactions. Facilitating embedded systems many requirements calls for new system architectures. One approach for designing system architectures is to integrate multiple operating systems on a multicore processor. In this approach, heterogeneous operating systems run different types of applications within the multicore system; a real-time operating system delivers real-time behavior such as low latency and predictable control function performance, and a versatile operating system processes applications developed for IT systems. However, this system architecture has a drawback. An unintentional failure of one operating system could overwrite important data and codes and bring down not only that operating system but others as well. This can occur because a CPU core, which executes operating system codes, can access any hardware resource on a multicore processor. We therefore need a partitioning mechanism to isolate any unintentional operating system failure within a domain to prevent it from affecting systems in other domains. A domain is a virtual resourcemanagement entity that executes operating system codes in a multi-operating system integrated on a multicore processor. System engineers have developed several partitioning mechanisms for servers and high-end desktop systems. 2,3 However, these mechanisms are unsuitable for an embedded multicore system-on-chip (SoC) /09/$26.00 c 2009 IEEE Published by the IEEE Computer Society Tohru Nojiri Yuki Kondo Naohiko Irie Hitachi Masayuki Ito Hajime Sasaki Renesas Technology Hideo Maejima Tokyo Institute of Technology... 7

2 ... COOL CHIPS 8 IEEE MICRO processor equipped with only the minimally required resources. Rather, they re for multiprocessor systems in which many processors share large amounts of memory and I/O devices. The mechanisms can t divide a small memory system into areas, nor segment a device into groups of channels to be assigned to multidomains on the multicore SoC processor. We ve therefore developed a lowoverhead domain-partitioning mechanism for a multidomain embedded system architecture that protects a domain from being affected by other domains on an embedded multicore processor. Additionally, we fabricated a multicore SoC processor incorporating a physical partitioning controller (), which is a hardware support for the domainpartitioning mechanism. Embedded systems trends Embedded systems were originally cost-sensitive control systems with a fixed function namely, to make the machine or mechanical parts operate in a specific and safe way to meet real-time performance constraints for reasons such as safety and usability. Embedded processors have the following characteristics: a simple CPU optimized for code efficiency and low power, low and predictable interrupt latency to support real-time control, occasional use of application-specific processors such as digital signal processors and media processors, and integration of on-chip ROM, RAM, and peripheral I/O devices to reduce system cost. These days embedded systems are going to incorporate IT as well as control functions, 4 and heterogeneous multicore processorswillbewidelyusedinembeddedsystems because it s difficult for a single processor architecture to support operation throughput for IT functions and real-time response for control functions. Automobiles, as embedded systems, increasingly use electronic subsystems to control mechanical parts such as the engine, transmission, brakes, and steering. Each subsystem has an electronic control unit (ECU) and a control application, which usually have a one-to-one relationship. Manufacturers enhance and network these subsystems together with the car area network (CAN) to implement new functions that maximize control and safety, such as antilock braking systems, electronic stability control, traction control, and automatic four-wheel drive. Furthermore, navigation systems and telematics, which provide IT functions such as databases and networking, will soon be integrated into car control systems, and control and IT functions will cooperate to increase automobiles safety, security, comfort, and usability. Because of their dramatically increasing complexity and functionality, embedded systems development can cost billions of dollars and take a decade to complete. Through software reuse, 5 organizations attempt to save development time and energy. Engineers have a library of software modules, many of which they use in multiple applications. Modern embedded systems will be based on two-domain system architectures: a realtime domain, consisting of real-time control applications on an RTOS; and an IT domain, consisting of IT applications on versatile operating systems. Programming model for embedded systems on multicore processors Figure 1 shows our multidomain system, built on a multicore processor. The system architecture lets the designer assign domains to the different CPU cores and implement them independently in each core. Applications and operating systems in both domains are largely unaware of each other. Domains might exchange information and coordinate tasks, but there is no dynamic load balancing. The task assignment is fixed, and hardware resources can be dedicated to the domains, resulting in a more deterministic performance. Despite some possible memory overhead due to multiple operating system images in the main memory, this feature is one of the system architecture s most significant advantages for embedded system developers. As embedded systems size and complexity increase, so do the chances that the system will break down because of software malfunctions or attacks over the network.

3 Steering Engine Real-time control applications Engine Sensor Transmission Brake Steering Real-time operating system Audio Multimedia IT applications Navi Telematics GUI Database operating system Net Versatile operating system Transmission CPU1 DMAC INTC Timer SCIF CPU 0 Brake GPIO ROM Con RAM Con DU PCI Car area network Dev ROM RAM Display Net DMAC: Direct memory access controller DU: Display unit GPIO: General-purpose I/O INTC: Interrupt controller SCIF: Serial communication interface Figure 1. Multidomain system architecture for embedded multicore processors. In this architecture, domains are assigned to different CPU cores and collaborate with each other to implement new functions. Although operating systems isolate software failures within an application, a failure could affect the operating system itself, causing it to bring down all applications running on it because operating systems, especially versatile ones, are becoming large and complex. In developing control subsystems whose failure might endanger a person s life, such as an automobile s brake control system, an engineer tries to achieve a high level of safety by every conceivable means. However, even a safe and secure control subsystem can be affected if it s incorporated with IT subsystems into a multidomain system on a multicore processor. Our domain-partitioning approach helps to isolate failures within unreliable IT domains rather than let them affect control domains on the multidomain embedded system. This domain partitioning protects a domain from being affected by other domains in the multidomain system and maintains the system s safety and security by allocating multicore processor resources for each domain to let it run its own operating system and applications 6 ; protecting a domain from the effects of software failure in other domains and ensuring that only the domain causing the failure is affected; resetting the domain and rebooting its operating system without letting the other domains observe any of the failure s effects; and lowering system performance overhead to less than 5 percent to implement fault isolation. Partitioning of multicore processor systems Partitioning techniques with hardware support fall into two categories: physical partitioning and logical partitioning. 2 Physical partitioning With physical partitioning, each domain uses dedicated processor resources. In the multidomain system in Figure 2a, system designers allocate each CPU core and each group of channels in multichannel devices DMA controllers (DMAC), timer units (TMU), and serial communication interfaces (SCIF) and other devices, such as the display unit, PCI, and general-purpose I/O NOVEMBER/DECEMBER

4 ... COOL CHIPS Real-time domain Partitioning IT domain CPU 2 INTC Timer Timer INTC CPU 0 CPU 1 Partition controller GPIO SCIF DMAC RAM Con DMAC SCIF DU PCI Real-time domain Partitioning IT domain Hypervisor CPU 2 INTC Timer CPU 0 CPU 1 GPIO SCIF RAM Con DMAC DU PCI Dev RAM Display Net Dev RAM Display Net (a) (b) Figure 2. Partitioning techniques. In physical partitioning (a), a hardware mechanism, such as a partitioning controller, controls the resources assigned to a particular domain. In logical partitioning (b), a programming layer called a hyperviser controls the resources so that multiple domains can share them. 10 IEEE MICRO (GPIO), to one of the domains. Each allocated resource is physically distinct from the resources used by the other domain. Although the domains share the on-chip system bus, each transaction is dedicated to a domain. This prevents the other domain from affecting transactions that concern issues other than bandwidth. In physical partitioning, each partition s configuration that is, the resources assigned to a domain is controlled in the hardware (such as the partition controller in Figure 2a), because physical partitioning doesn t require sophisticated algorithms to schedule and manage resources. When the system boots up, the partition controller sets up the hardware resources to use in a partition according to partition-configuration commands. Once a partition is configured, the operating systems are loaded into each partition, and a domain on each partition starts to run the operating system and applications. The partition controller checks every access request for hardware resources that the operating system and applications generate and invalidates any unauthorized requests. Failure isolation and predictable resource allocation are physical partitioning s two most important goals. Although physical partitioning sacrifices flexibility in allocating resources to partitions to achieve these goals, it s typically easy to implement with hardware and imposes little overhead on application execution. Logical partitioning With logical partitioning, domains share some physical resources, usually in a timemultiplexed manner. Thus, logical partitioning makes it possible to run multiple operating system images on a single hardware system and enables dynamic workload balancing. Logical partitioning is used to implement virtual machines on PC servers and mainframes to optimize utilization of hardware resources. Logical partitioning is more flexible than physical partitioning but requires additional mechanisms to provide the services needed to share resources safely and efficiently. Usually, a hypervisor that is, a programming layer lower than the operating system and hidden from general system users (see Figure 2b) controls each partition s configuration.when the system boots up, the hypervisor sets up the hardware resources for use in a partition according to the partition configuration commands. Once a partition is configured, the hypervisor loads the operating systems and applications into each partition, and a domain on each partition starts to run them. During execution of the operating system and applications on the partition, the hypervisor traps every hardware resource access request that the operating system and applications generate to check their authenticity and to provide the requested resource services if authorized. Optimizing hardware utilization is one of logical partitioning s important goals.

5 LCPG INTC CPU 0 CPU 1 DMAC PCIe SHPB L2$ Internal system bus HPB WDT TMU HAC Peripheral bus Ether USB DU LBSC DBSC CPG GPIO HSPI SCIF I2C SSI SDIF ROM RAM CPG: Clock pulse generator DBSC: DDR3-SDRAM memory controller HAC: Audio codec I/F HPB: H-Peripheral bus HSPI: High-speed parallel interface I2C: Inter IC bus LBSC: Local bus state controller LCPG: Local clock pulse generator SDIF: Sound description interchange format SHPB: SH-Peripheral bus SSI: Serial sound I/F TMU: Timer unit WDT: Watch dog timer Figure 3. Block diagram of the multicore SoC processor we used to implement the proposed domain-partitioning technique. To achieve this goal, logical partitioning sacrifices the partition s physical isolation in exchange for greater flexibility in dynamically allocating resources to partitions. It also imposes performance penalties because the hypervisor is implemented in software layers. Our approach In terms of hardware design simplicity, implementing the partition controller for physical partitioning of embedded processors involves a small amount of memory and a simple logical circuit and doesn t require any architectural changes to the CPU core. However, to mitigate logical partitioning s original virtualization performance overhead, logical partitioning imposes several challenges on the CPU core architecture, such as introducing a new execution mode on the CPU core. 7 In terms of software development simplicity, physical partitioning requires a new error-handling routine for the partition controller that can be implemented as a simple interrupt handler in embedded systems and doesn t require modifying guest operating systems. However, logical partitioning requires a hypervisor to arbitrate accesses to the underlying physical hardware resources so that multiple guest operating systems can share them. Its paravirtualization approach improves virtualization performance but requires modifying the guest operating systems. 8 In typical multidomain embedded systems,eachdomain scpu,memoryarea, and peripheral devices are physically different, and physical isolation and low overhead are more important than partitioning flexibility. Therefore, we based our domain partitioning on physical partitioning techniques and use the hardware module to implement physical isolation with low overhead. Multicore processor with domain-partitioning mechanism Figure 3 is a block diagram of the multicore processor we used to implement the proposed domain-partitioning technique. The processor is a multicore SoC containing NOVEMBER/DECEMBER

6 ... COOL CHIPS 12 IEEE MICRO two SH-4A processor cores, each of which is a 32-bit RISC microprocessor containing an instruction cache, data cache in write-back mode, and memory management unit (MMU) with a translation look-aside buffer (TLB), which supports a 32-bit virtual address space. The SH-4A cores maintain consistency between data caches and share an instruction/data unified L2 cache in writethrough mode. The processor incorporates a DDR3-SDRAM memory controller (DBSC), local bus state controller (LBSC) supporting connection to burst ROM, a DMAC, a sophisticated interrupt controller (INTC), and several on-chip peripherals including the display unit, Ethernet controller, GPIO, and SCIF. These hardware modules are connected through an internal system bus and a peripheral bus. SHPB and HPB are bus bridges that connect the internal system bus with the peripheral bus. The CPU cores, display unit, ether, and USB are initiator modules that can request access to other modules connected to the internal system bus. HPB, SHPB, LBSC, and DBSC are target modules that initiators can access through the internal system bus. DMAC and PCI Express (PCIe) areinitiatormodulesaswellastargetmodules on the internal system bus. These hardware modules are mapped onto the processor s physical address space, which the initiators use to gain access to processor resources. In the multidomain system architecture we are proposing, system designers assign domains to the different CPU cores and processor resources, such as memory and peripherals. They might also allocate shared memory resources that the domains can use to communicate with each other. The operating system in each domain controls the CPU cores and the other initiator modules so that they use the assigned processor resources. Thus, the applications running on the operating system can t use the processor resources assigned to another domain. However, as we mentioned previously, the system could break down due to unintentional software malfunctions in the operating system because the CPU core can access any processor resources. An access-control mechanism in the multicore SoC processor can help prevent such access. Access control of physical partitioning controller The is located between the access initiator modules and the access target modules. It checks every access request and blocks requests that aren t authentic. The contains an access checklist (ACL) to set access authorization rules, and the ACL defines the processor s partition configuration. The ACL consists of several register entries, each having three fields: an SRC field, which specifies an access initiator; a DEST field, which specifies an access target; and an AUTH field, which specifies authorized operation for both the SRC and DEST fields. The processor has multiple channel devices, such as a DMAC, PCIe, TMU, SCIF, audio codec I/F (HAC), serial sound I/F (SSI), and I2C. The segments them into groups of channels and recognizes each group as a separate module so that each domain uses one group s function exclusively. The also segments RAM and ROM into several memory areas so that a domain can use them as private memory. Moreover, several domains can access a shared RAM area to communicate with each other. Therefore, the recognizes each initiator and target, indicated in Figure 4, as separate modules. We assigned a SrcID to each initiator module and used a control register address as an identifier for the DEST field. The size of the address range should be a power of 2, and its start address should be a multiple of the alignment, which must be a power of 2 and a multiple of the size of the address range. Implementation of Figure 5 shows the structure. The SRC field consists of an SrcID and an SrcID mask; the DEST field consists of an address and address mask; and the AUTH field consists of two bits one for read permission and one for write permission. The checks every access request by comparing a set of operation, target address, and SrcID with all ACL entries using the logical

7 Initiators CPU 0 CPU 1 DMAC 0 5 DMAC 6 11 PCIe 0 PCIe 1 PCIe 2 DU Ether USBF Access checklist (ACL) SRC DEST AUTH CPU 0 Mem A#0 CPU 1 CPU 0 CPU 1 Mem A#1 GPIO DU CPU 0 DMAC CPU 1 DMAC CPU 0 SCIF CPU 1 CPU 0 CPU 1 DMAC DMAC CPU 0 CPU 1 SCIF TMU TMU Mem A#0 Mem A#1 INTC INTC Targets RAM DBSC Area 0 Area 1 Area C ROM LBSC Area 0 Area 1 Control registers DMAC DMAC 0 5 CPG DMAC 6 11 WDT GPIO DU PCI TMU 0 2 PCIe 0 TMU 3 5 PCIe 1 TMU 6 8 PCIe 2 TMU 9 11 HSPI SHPB HAC0 INTC HAC1 INTC2 USBF LCPG 0 USBH LCPG 1 HPB SDIF0 SDIF1 SCIF0 SCIF1 SCIF2 SCIF3 SCIF4 SCIF5 SSI0 SSI1 SSI2 SSI3 I2C0 I2C1 USBH Figure 4. Physical partitioning controller (). Initiator modules request access to target modules through the internal system bus. The checks every access request on the internal system bus to analyze their authenticity. circuit shown in the figure. When the finds a match for an ACL entry, it authorizes the access request, and the passes the access request to the target module. When the finds no match for an ACL entry, it doesn t authorize the access request, and the blocks it and generates a deny signal to start error handling. The modules are located between the internal system bus and the bus target modules that is, the DBSC, SHPB and HPB bus bridges, PCIe, and DMAC (see Figure 6). The has six subblocks DSBC-, LBSC-, SHPB-, HPB-, DMAC-, and PCI- each of which has its own set of registers and ACLs. Table 1 lists the number of ACL entries of each. For SHPC-, HPB-, DMAC-, and PCI-, the initiators are CPU cores and the targets are modules connected on the bus-target modules; therefore an ACL entry is needed for each target to authenticate an access from the CPU core of the domain. For LBSC-, CPU cores gain access to two ROM areas that are each allocated to a domain; therefore, LBSC- needs an ACL entry for each ROM area. For DSBC-, the initiators, which are two CPU cores and nine initiator modules, access two dedicated RAM areas and a shared RAM area; therefore, this subblock needs 11 entries for the dedicated RAM areas and 11 entries for the shared RAM area. error handling When these conditions aren t satisfied, the judges the access to have been NOVEMBER/DECEMBER

8 ... COOL CHIPS Access control list (ACL) Op Address SrcID Address Mask[31:xx] SrcID Mask[7:0] Address Mask[31:xx] SrcID Mask[7:0] Address Address Mask[31:xx] SrcID SrcID[7:0] Mask[7:0] Address Mask[31:xx] SrcID Mask[7:0] Address [31:xx] SrcID[7:0] Address [31:xx] SrcID[7:0] Address [31:xx] SrcID[7:0] PRd PRd PRd PWr Pwr PWr PWr Prd Read Write = = = = Deny Figure 5. Access control of physical partitioning controller. The consists of a simple logical circuit and access checklist (ACL) registers to check the authenticity of access requests by comparing a set of operation, target address, and the SrcID with an ACL. error handler Real-time control applications INT RTOS handler Partitioning IT applications Versatile OS INT handler LCPG INTC CPU 0 CPU 1 DMAC PCIe SHPB L2$ Internal system bus HPB WDT TMU HAC Peripheral bus Ether USB DU LBSC DBSC CPG GPIO HSPI SCIF I2C SSI SDIF ROM RAM Registers for access-violation handling ERRADD Bus address information ERROPC Bus access type and size ERRSRC Identity of bus-source module ERROVL Multiple access Figure 6. Implementation of the physical partitioning controller. Each of the six subblocks has its own set of registers and an access checklist (ACL) to check access requests for the target module of their charge. 14 IEEE MICRO

9 Table 1. Number of access checklist (ACL) entries for each physical partitioning controller. Initiator Target No. of ACLs needed No. of ACLs implemented LBSC- 2 CPU cores 2 ROM areas 2 4 DBSC- 2 CPU cores, 2 RAM areas allocated to a domain, initiator modules 1 RAM area shared by domains SHPB- 2 CPU cores 4 target modules 4 8 HPB- 2 CPU cores 27 target modules DMAC- 2 CPU cores 2 target modules 2 4 PCI- 2 CPU cores 3 target modules 3 4 inauthentic and rejects it. The then sends an error response to the internal system bus instead of passing the access request to the target module. The also generates an access-violation interrupt signal, which is transmitted to the INTC. The INTC prioritizes interrupt sources and controls the flow of interrupt requests to the CPU. The INTC has registers for prioritizing each interrupt, and it processes interrupt requests following the priority order set in these registers by the program. Most oftheseregistersaresystemwide,sothey can t be physically partitioned. Therefore, we assumed that the real-time domain would be more reliable than the IT domain, and we decided that CPU 0, which houses the real-time domain, should be allowed to access the INTC registers and the IT domain should send requests to the real-time domain for operation on the registers. When the INTC receives an accessviolation interrupt signal, the execution jumps to the start address of the errorhandling routine. Each subblock has registers that determine the access-violation interrupt signal s behavior and hold the information on rejected access requests. Based on this information, the error-handling routine classifies the access violation s seriousness and decides whether the system should be rebooted. Evaluation We fabricated two embedded dual-core processors that incorporate several on-chip peripheral modules and the. We implemented one using 90-nm CMOS process technology with typical-case design methodology for an experimental chip operating at a Figure 7. Chip micrograph. We implemented this embedded dual-core processor using 65-nm CMOS process technology with worst-case design methodology for a product chip operating at 533 MHz. 600-MHz clock frequency, and the other with a rich set of on-chip peripherals using 65-nm CMOS process technology with worst-case design methodology for a product chip operating at 533 MHz (Figure 7). Designing and implementing the is so simple that its design impact was negligible in terms of chip area. In addition, we didn t find any critical path due to in the timing analysis of thee chips development. To evaluate the performance overhead of -based domain partitioning, we used the LMBench 9 benchmark program and compared bare Linux with Linux on top of a error handler, run on the 90-nm CMOS processor. In this evaluation, we implemented the error handler as an interrupt/exception service routine that NOVEMBER/DECEMBER

10 ... COOL CHIPS Table 2. Performance evaluation results for memory latency and context switching times using LMBench. Context switching times (ms) (Number of Operating Memory latency (ns) processes/process image size [in bytes]) system L1 cache Main memory Random memory 2p/64k 8p/64k 16p/64k Linux , Linux error handler Overhead (%) Table 3. Performance evaluation results for processing times using LMBench. Process times (ms) Operating system Null call Null I/O Signal install Signal handling Fork processing Execution processing Linux , , Linux , , error handler Overhead (%) IEEE MICRO handled the access-violation error and related system calls. So that we didn t have to modify the Linux, we implemented the handler like a hypervisor outside of the operating system. Therefore, the error handler checked whether the event was related to the in response to interrupts or exceptions and passed the processing to the appropriate normal service routine in the Linux if unrelated; otherwise, the error handler rebooted the Linux, causing a serious access-violation error. To observe the domain partitioning using, we injected access-violation errors by configuring so that it didn t allow applications running on Linux to access a small memory area assigned to Linux. When the application wrote some data into the small memory area, the rejected the write access request so that no data was written in the memory area and the generated access-violation interrupt signal to initiate a error handler to reboot the Linux. Tables 2 and 3 show the overhead of domain partitioning using the. The average performance penalty was 2.49 percent and the overheads were typically less than 5 percent. In memory latency cases, the overheads were due only to the additional bus access cycle generated by implementing because the error handler was not initiated during the tests; thus, the overhead was 0.0 percent for the L1 cache, 1.48 percent for main memory, and 3.85 percent for random memory. We presumed that the overhead difference between main and random memories was due to the effect of the CPU core store buffers. The worst cases of overhead were percent for null call and percent for null I/O. We attributed this overhead to the error handler because null call and null I/O are system calls that only generate exceptions that trigger the error handler s execution. Implementing the error handler into the Linux service routine using a paravirtualization approach 8 could reduce the overhead. Overall, our proposed multidomain embedded system architecture with a partitioning mechanism for embedded multicore processors is well suited to developing cost-conscious embedded systems. Although this article focuses on the domainpartitioning technology, we also need to discuss techniques for secure interdomain communication and collaboration in multidomain embedded systems, such that the domains cooperate more tightly to implement a higher level of functionality. Because

11 embedded systems requirements will change in the future, we should develop system architectures suitable for implementing them optimally. Therefore, we don t intend the proposed architecture to be the definitive solution for embedded system development; rather, we hope that the problems discussed in this article will inspire new solutions. MICRO References 1. C. Ebert and C. Jones, Embedded Software: Facts, Figures, and Future, Computer, vol. 42, no. 4, Apr. 2009, pp J.E. Smith and R. Nair, Virtual Machines: Versatile Platforms for Systems and Processors, Morgan Kaufmann, Sun Microsystems, Sun Enterprise Server: Dynamic System Domains, white paper, 1999; docs/domainswp.pdf. 4. H. Takada and S. Honda, Real-Time Operating System for Function Distributed Multiprocessors, J. Information Processing Soc. of Japan, vol. 47, no. 1, Jan. 2006, pp C. Kruger, Software Reuse, ACM Computing Surveys, vol. 24, no. 2, June 1992, pp K.J. Nesbit et al., Multi-Core Resource Management, IEEE Micro, vol. 28, no. 3, May/June 2008, pp R. Uhlig et al., Intel Virtualization Technology, Computer, vol. 38, no. 5, May 2005, pp P. Barham et al., Xen and the Art of Virtualization, Proc. 19th ACM Symp. Operating Systems Principles, ACM Press, 2003, pp L.W. McVoy and C. Staelin, Lmbench: Portable Tools for Performance Analysis, Proc. Usenix Ann. Technical Conf., Usenix Assoc. 1996, pp Tohru Nojiri is a senior researcher at Hitachi s Central Research Laboratory, and a PhD student in the Department of Information Processing at the Tokyo Institute of Technology. His research interests include embedded system platform, operating system, and processor architecture. Nojiri has a BE in mathematical engineering from the University of Tokyo. He is a member of IEEE Computer Society, the ACM, and the Information Processing Society of Japan. Yuki Kondo is a researcher at Hitachi s Central Research Laboratory. His research interests include the architecture of embedded systems. Kondo has an ME in computer science from the Tokyo Institute of Technology. Naohiko Irie is the head of the planning office at Hitachi s Central Research Laboratory. His research interests include processor architecture of mainframe, symmetric multiprocessing servers, and embedded processors. Irie has an ME in information systems from Kyushu University, where he has also served as a visiting professor. He is a member of the Information Processing Society of Japan. Masayuki Ito is the group manager of the CPU Development Department at Renesas Technology. His research interests are in developing CPU cores, in particular, lowpower microprocessor design. Ito has an MS in computer engineering from Kyoto University. Hajime Sasaki is a senior engineer of the Car Information System Design Department at Renesas Technology. His research interests are in developing SoC processor for car information systems. Sasaki has an BS in electrical and electronic engineering from Kitami Institute of Technology. Hideo Maejima is a professor in the Department of Information Processing, Graduate School, Tokyo Institute of Technology. His current interests include multi/ manycore architecture, and reconfigurable computing and integrated development environments. Maejima has a PhD in computer science from the Tokyo Institute of Technology. He is a member of IEEE Computer Society and the Information Processing Society of Japan, and a Fellow of the Institute of Electronics, Information, and Communication Engineers. Direct questions and comments to Tohru Nojiri, Central Research Laboratory, Hitachi, Ltd., 1-280, Higashi-koigakubo, Kokubunji-shi, Tokyo, Japan; tohru.nojiri.gg@hitachi.com. NOVEMBER/DECEMBER

12 This article was featured in For access to more content from the IEEE Computer Society, see computingnow.computer.org. Top articles, podcasts, and more. computingnow.computer.org