next up previous contents index
Next: 1.2 Application Modeling Up: 1. Introduction Previous: 1. Introduction   Contents   Index


1.1 System Level Design

Modern stream processing systems such as digital televisions, set-top boxes, and mobile devices are multi-functional systems that support multiple standards. For example, consider a digital TV set which receives an MPEG transport stream via digital video broadcast. In this TV set the MPEG transport stream is demultiplexed into a number of MPEG video streams, and these MPEG video streams are decoded, scaled, and merged for display. Via a remote control unit a user can select the channels to be displayed, including the size and position of the video windows.

Figure 1.1: Embedded System Architecture
\begin{figure}\centerline{\epsfig{file=Figures/embedded.eps,width=0.35\textwidth}}\end{figure}

Now assume that a system designer is facing the challenge to implement the functionality in an embedded system. In embedded systems the user-interface functionality is typically handled in software because the system should have the flexibility to deal with rapidly changing functional specifications. For other functions a software implementation is essential to be able to deal with multiple standards or with multiple languages in different countries, for example. The embedded system shown in Figure 1.1 has one CPU on which the software tasks run, for instance, to handle the events from the remote control. For the video processing functions like MPEG decoding and video scaling, a software implementation may be inappropriate because of the high data rates that are involved. The performance requirements and the constraints on silicon area and power consumption require that significant parts of the system are implemented in dedicated hardware blocks that run in parallel with the CPU. As a consequence, the system has a heterogeneous architecture, i.e., it consists of programmable and dedicated components. Besides the processors the system also contains other elements. A ROM may contain program code for the software tasks that run on the CPU. RAM, caches and buffers provide storage for temporary data, and a bus provides resources for inter-processor communication.

Figure 1.2: The Y-chart: a general scheme for heterogeneous system design.
\begin{figure}\centerline{\epsfig{file=Figures/ychart.eps,width=0.7\textwidth}}\end{figure}

In our view the design of these heterogeneous multi-processor architectures should follow a general scheme, visualized by the Y-shape in Figure 1.2, hence, the name Y-chart [18] [1].

In the Y-chart we distinguish between four activities. The first activity is Application Modeling. The purpose of this activity is to capture a functional specification of the system in the form of a set of benchmark applications. The application modeling is done by a person we refer to as application designer. The second activity in the Y-chart is Architecture Modeling. The purpose of this activity is to model the resources that are available in the system. In embedded systems these resources typically are processors, operating systems, buses and memories. Another important resource is time. In the third activity, the Mapping, the function is mapped onto the resources of the architecture. The result of the mapping is an implementation of the system which can be used as input for the fouth activity, Performance Analysis.

Typically, a system designer studies the set of benchmark applications, makes some initial calculations and proposes an architecture. Architectures are evaluated quantitatively by means of performance analysis. To this end, each application is mapped onto the architecture and the performance of each application-architecture-mapping combination is evaluated. The resulting performance numbers may inspire the architecture designer to improve the implementation via another mapping, or by choosing other resources in the architecture. He may also decide to restructure the applications, for instance if the performance requirements cannot be met with the given resources. The system designer actions are denoted by the light bulbs in Figure 1.2.


next up previous contents index
Next: 1.2 Application Modeling Up: 1. Introduction Previous: 1. Introduction   Contents   Index
© Copyright Koninklijke Philips Electronics NV 2006