Hideo Maejima

A 45nm 37.3GOPS/W heterogeneous multi-core SoC

We develop a heterogeneous multi-core SoC for applications, such as digital TV systems with IP networks (IP-TV) including image recognition and database search. Figure 5.3.1 shows the chip features. This SoC is capable of decoding 1080i audio/video data using a part of SoC (one general-purpose CPU core, video processing unit called VPU5 and sound processing unit called SPU) [1]. Four dynamically reconfigurable processors called FE [2] are integrated and have a total theoretical performance of 41.5GOPS and power consumption of 0.76W. Two 1024-way matrix-processors called MX-2 [3] are integrated and have a total theoretical performance of 36.9GOPS and power consumption of 1.10W. Overall, the performance per watt of our SoC is 37.3GOPS/W at 1.15V, the highest among comparable processors [4–6] excluding special-purpose codecs. The operation granularity of the CPU, FE and MX-2 are 32bit, 16bit, and 4bit respectively, and thus we can assign the appropriate processor for each task in an effective manner. A heterogeneous multi-core approach is one of the most promising approaches to attain high performance with low frequency, or low power, for consumer electronics application and scientific applications, compared to homogeneous multi-core SoCs [4]. For example, for image-recognition application in the IP-TV system, the FEs are assigned to calculate optical flow operation [7] of VGA (640×480) size video data at 15fps, which requires 0.62GOPS. The MX-2s are used for face detection and calculation of the feature quantity of the VGA video data at 15fps, which requires 30.6GOPS. In addition, general-purpose CPU cores are used for database search using the results of the above operations, which requires further enhancement of CPU. The automatic parallelization compilers analyze parallelism of the data flow, generate coarse grain tasks, schedule tasks to minimize execution time considering data transfer overhead for general-purpose CPU and FE.

Domain Partitioning Technology for Embedded Multicore Processors

Todays 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 systems 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.

A 200 MHz 1.2 W 1.4 GFLOPS microprocessor with graphic operation unit

This 200 MHz CMOS 2-issue superscalar microprocessor is redesigned with a 0.25 /spl mu/m 5-metal-layers CMOS process (L/sub eff/=0.20 /spl mu/m). In this chip 3.2M transistors are implemented in a 7.6/spl times/7.6 mm/sup 2/ die. This chip for low-cost graphic, embedded applications achieves 1.4 GFLOPS at 200 MHz with low-power consumption. This chip integrates CPU, FPU, 8 kB direct-mapped instruction cache (IC), 16 kB direct-mapped data cache (DC), MMU (64-entry unified TLB and 4-entry ITLB), bus interface logic, and six peripherals which are DMAC, timer unit (TMU), real time clock (RTC), serial comm. interface (SCI), interrupt controller (INTC), and emulation/debug unit (EMU). The bus interface provides glueless connections to SRAM, DRAM, SDRAM, burst-ROM, and PCMCIA, bus operation includes 8-, 16-, 32-, and 64b bus widths.

TCBC: Trap Caching Bounds Checking for C

In this paper, we propose a debugging technique for C, which can dynamically find boundary errors on strings in a highly-compatible, accurate and efficient manner. The main idea of our technique is to effectively keep track of hazardous memory bounds (called trap regions) using a small table (called a trap cache) on the static section of the instrumented program. We have implemented our technique as an extension of GCC4.1.1 and conducted experiments. The results show that our technique was easily applicable even to large real programs including Apache 1.3.37 and Linux 2.6.20.4 without requiring significant manual effort, it successfully detected all of ten known boundary errors in them with no false positives, and it incurred low run-time overheads (average 17%) for their benchmarks.