Trends in Reconfigurable Embedded Systems

Introduction

Embedded systems are designed to perform dedicated specific tasks with real-time processing constraints. Such systems comprise complete devices ranging from portable such as video cameras and set-top boxes, to complex industrial controllers including mechanical parts.

Embedded systems complexity varies from a single microcontroller to several interrelated dedicated functional units, peripherals and network devices. Often they come with contradictory design constraints such as low power consumption and high performance. Indeed, mass production portable devices should be cheap and power efficient. On the other hand, they still need to support multiple, sometimes real-time, applications and standards. The wide spectrum of design requirements leads to complex architectures composed by several processors and customized hardware components. These multiprocessors System-on-chip (MpSoC) have now become the foundation of most common appliances such as digital TV, navigation systems and wireless devices.

One of the major challenges on embedded systems design is to obtain the necessary system performance with efficient utilization of hardware resources. To accomplish this goal, the system must be optimized in power consumption, size and cost, complying with flexibility, reliability and processing performance requirements. The architecture must support multiple applications and standards. Targeting the architecture to a single application prevents its evolution and flexibility. Accuracy at the early design stage is not an option; low level simulation suffers from low simulation speed and design effort. Such conflicting design requirements cannot be satisfied by traditional design methods (Pimentel, Lieverse, & Van der Wolf, 2001).

Classical hardware/software codesign methodology was typically based on system level specification refinement forcing the designer to make early decisions regarding system architecture (Coumeri & Thomas, 1995) (Kim, et al., 1995) (Bauer & Ecker, 1997) (Balarin, et al., 1997) (Hines & Borriello, 1997). A system-level model represents application behavior, architecture characteristics and the relation between application and architecture (application partitioning, mapping and resources utilization). One essential design task is to perform design space exploration at the early design stages. System level simulation is here used to provide a first estimate on system performance (for instance, power consumption or cost) and to make early decisions on various design parameters (Pimentel, Erbas, & Polstra, 2006) (Balarin, Watanabe, Hsieh, Lavagno, Passerone, & Sangiovanni-Vincentelli, 2003) (Stammermann, Kruse, Nebel, & Pratsch, Oct. 2001) (Gadient, Debardelaben, & Madisetti, 1997). Using a high abstraction level minimizes the modeling effort increasing simulation speed. Several possible implementations can be rapidly evaluated at the system-level prior to the refinement (at the instruction-level, cycle-accurate or register-transfer level) and synthesis.

Recent work, Y-chart methodology, recognizes a clear separation between application and architecture models: an explicit mapping step relates the application model to the architecture model (Balarin, et al., 1997) (Kienhuis, Deprettere, Vissers, & Van der Wolf, 1997) (Lieverse, Stefanov, Van der Wolf, & Deprettere, Nov. 2001) (Zivkovic, Van der Wolf, Deprettere, & De Kock, Oct. 2002) (Mohanty & Prasanna, 2002) (Balarin, Watanabe, Hsieh, Lavagno, Passerone, & Sangiovanni-Vincentelli, 2003). The application model describes only functional behavior of an application, independently of architecture characteristics or timing parameters. The application concerns are clearly separated in computational and communication events. The architecture model defines architecture resources, capturing timing characteristics and performance consequences of an application event. The latter involves simulation of programmable as well as reconfigurable or dedicated components. The mapping of each application onto an architecture instance is evaluated by a performance analysis. The resulting performance numbers may inspire the designer to improve the architecture, restructure the application, or change the mapping.