Simulink based Hardware-Software Codesign Flow for Heterogeneous MPSoC
Katalin Popovici
TIMA Laboratory
46 Avenue Felix Viallet
38031, Grenoble, France
katalin.popovici@imag.fr
Keywords: hardware-software gradual refinement,
multimedia applications, abstraction levels
Abstract
SystemC based design methodology has been widely
adopted for heterogeneous multiprocessor System on Chip
(MPSoC) design. However, SystemC is hardware-oriented
language and it is not the standard language used by
designers to specify complex applications at algorithm level.
On the other hand, Simulink is a popular choice for
algorithm designer to specify complex system, but there are
few design tools to implement Simulink models on MPSoC.
To deal with the increasing complexity of embedded
applications and MPSoC architectures, concurrent
hardware/software design and verification at different
abstraction levels is an essential technique. In this paper, we
present a Simulink-SystemC based multiprocessor SoC
design flow that enables mixed hardware/software
refinement and simulation at different abstraction levels in
addition to opening new facilities like communication
mapping exploration and interconnection component
refinement. We applied the proposed approach for software
and communication architecture refinement for three
multimedia applications: MP3, Motion JPEG and H.264.
1. INTRODUCTION
Current embedded systems require a flexible and high-
performance architecture to execute concurrently specific
applications, including MPEG 2/4, H.263/4, CDMA 2000,
WCDMA, and MP3. Heterogeneous multi-processor
System on Chip (MPSoC) architecture is becoming an
attractive solution because it provides highly concurrent
computation and flexible programmability [1]. However, as
the complexity of system increases, it is more difficult and
time consuming to develop and verify MPSoC software and
hardware. To solve the problem, new design methodology
and language are needed.
SystemC [2] has become the preferred development
language for hardware/software to overcome the design
complexity problem. SystemC, which is based on C/C++,
provides the abstraction and constructs needed for high-
SCSC 2007
Ahmed Amine Jerraya
CEA LETI Minatec
17 Rue des Martyrs
38054, Grenoble, France
ahmed.jerraya@cea.fr
level system modeling and verification. Such abstraction,
primarily at the transaction-level, allows much faster
simulations and analysis, and enables design issues to be
detected early in the process. Several academic [3] and
industrial research projects [4] proposed automatic MPSoC
design flows from SystemC model. Therefore, SystemC can
be a good candidate to design complex MPSoC. However,
SystemC is still hardware-oriented language and not suitable
to specify, analyze, design and verify the overall application
at algorithm level.
For the algorithm modeling, simulation and validation,
Simulink has become a popular choice for many system
designers [5]. Simulink offers a block set of algorithms for a
variety of applications. System designer can develop a
model easily by combining the pre-defined blocks or user-
defined blocks called S-Functions. Simulink also provide
system designers with simulation environment to verify the
developed algorithm model. Real-Time Workshop (RTW)
and Simulink HDL Coder can automatically generate
software (C code) and hardware (VHDL/Verilog) code from
the algorithm model. However, mapping and refining
algorithm models onto complete MPSoCs is still an open
issue in the Simulink community.
In this paper, we propose a hardware-software co-
design flow that enables gradual MPSoC design from a high
level application model. The high level application model
combines the algorithm with partitioning and mapping
information. From this initial model captured in Simulink,
the hardware and software are gradually refined and
simulated at different abstraction levels using SystemC.
Additionally, the proposed flow allows for experimentation
with different communication mapping schemes and
integration of different types of network components for the
global interconnection: bus based or Network on Chip
(NoC) based architectures. The main contribution of this
work is the definition of the representation models at the
different abstraction levels.
The rest of the paper is organized as follows. Section II
presents previous work on Simulink and SystemC based
design flows. Section III defines the four abstraction levels
adopted in the proposed flow and the hardware/software
representation models at each abstraction level. Section IV
497 ISBN # 1-56555-316-0
describes the main steps of the overall flow. Section V
shows experiment results for three multimedia applications
(MP3, Motion JPEG and H.264). Finally, section VI draws
some conclusions.
2. RELATED WORKS
To handle the ever increasing complexity of MPSoC
design, System Level Design (SLD) methodology has been
proposed as the solution [5]. The key techniques are raising
abstraction level and decoupling communication from
computation. SystemC allows communication and
computation modeling at both levels of abstract, transaction
and RT (Register Transfer) level and it is well adopted to
implement SLD methodologies. Several academic (for
instance ROSES [3]) and industrial (for instance Coware
[4]) tools are proposed to generate MPSoC automatically
from the SystemC Transaction level modeling. However,
SystemC is still oriented to hardware designer and not
standard language used by designers to specify complex
system at algorithm level.
Simulink is widely accepted as a system level design
language and there are several design flows to generate
hardware and software automatically. However, the target
architecture is single processor. For instance, Real Time
Workshop [5] can generate C code from a Simulink model.
But, the generated C code can support only single task on
single processor. In [6], they can generate an optimized HW
RTL from a MATLAB/Simulink model. But they can
accept a restricted subset of MATLAB/Simulink model and
don’t handle software refinement for a multiprocessor
architecture.
MATCH [7] can generate software and hardware code
automatically from MATLAB description for configurable
computing systems. MATCH is targeted to a fixed
heterogeneous architecture composed with FPGAs (Field-
Programmable Gate Arrays), RISCs (Reduced Instruction
Set Computers), and DSPs (Digital Signal Processors) and it
does not generate SystemC models to allow design space
exploration.
This paper provides a design flow that can generate
SystemC model from Simulink model for multitasking
heterogeneous multiprocessor architecture. The generated
SystemC model allows early performance estimation and
communication mapping exploration.
3. HARDWARE/SOFTWARE DESIGN FLOW
3.1. MPSoC Hardware/Software architecture
The MPSoC design flow proposed in this paper is based
on a generic heterogeneous MPSoC hardware-software
architecture (figure 1-a) [8].
The different processor and hardware processing
subsystems interact via a complex communication network.
ISBN # 1-56555-316-0
A processor subsystem (figure 1-b) is a programmable
subsystem that includes a parallel processing unit for
computation and specific hardware components such as
local memories, peripherals and hardware accelerators. In
heterogeneous MPSoC architectures, different kinds of
processing unit may be needed (i.e. DSP for data oriented
operations, RISC for control oriented operations and ASIP
for application specific computation).
Each processor subsystem executes a specific software
stack organized in two layers, the application and the
hardware dependent software (HdS) layer (figure 1-c). The
top layer is the software application and it makes use of HdS
Application Programming Interface (HDS_API) to abstract
the underlying platform.
The HdS allows the execution of the high level code on
the hardware platform. The HdS layer is associated with the
hardware dependent low level software behavior, such as
interrupts routine services, context switch and specific I/O
control. In fact, it is made of lower software layers that may
include an operating system (OS), specific I/O
communication and hardware abstraction layer (HAL).
This mixed hardware-software representation of the
MPSoC architecture can be modeled using different levels
of details by abstracting the low level software layers,
processors and communication topology, as it will be
presented in the following section.
Task 1 Task 2 Task n
Appli-
SW cation
Mem CPU
HW SS CPU SS HDS_API
Specific
OS
I/O SW
HdS
Network HAL_API
Communication Periph.
interface Hardware Abstraction
network
Layer (HAL)
a) Generic architecture b) HW architecture c) SW stack executed by
of CPU subsystem a CPU subsystem
Figure 1. MPSoC Hardware/Software Architecture
3.2. MPSoC abstraction levels
The mixed hardware software architecture concept
allows modeling a heterogeneous MPSoC at different
abstraction levels, independent from the description
language used by the designer. In this paper we will
consider four abstraction levels [9-11].
The highest abstraction level is called System
Architecture; the lowest and fully detailed one is called
Virtual Prototype. Between these levels exists a huge gap in
terms of hardware-software interfaces, as it will be detailed
in the next sections. In order to reduce the gap between
these levels, we defined two intermediate abstraction levels:
the Virtual Architecture and the Transaction Accurate
Architecture level [12].
498 SCSC 2007
 SW-SS1 SW-SS2 consists of the set of subsystems and inter-subsystem
T1 T2 T3
communication units. The simulation at this level allows
F1 F2 F3 F4 validation of the application’s algorithm. In this paper we
COMM3
use the standard Simulink environment to represent the
System Architecture model.
COMM1 The second level is the virtual architecture level (VA)
COMM2 (figure 2.b). The application functions are refined to C code
a) System Architecture for each task. In order to abstract the underlying hardware
T2 T3
Abstract CPU-SS1 Abstract CPU-SS2 architecture, the tasks code uses HdS APIs. The
T1
MEM
T2 T3
communication primitives of the HdS API (send/recv)
COMM1
HdS API
access explicit communication components. The software is
SWFIFO
executed using an abstract model of the hardware
COMM2 Abstract CPU-SS
architecture that provides an emulation of the HdS API. The
hardware platform is composed of these abstract
Abstract Communication Network
subsystems, abstract interconnection component and storage
b) Virtual Architecture
T3
resources. The simulation at this level allows validation of
T2

CPU-SS1 MEM SS CPU-SS2

Abstract Abstract
CPU1 Memory
COMM1 CPU2
Interface Periph. COMM2 Interface
Communication Network (Bus/NoC)
c) Transaction Accurate Architecture
CPU-SS1 MEM SS
CPU-SS2
CPU1 ISS Memory
COMM1 CPU2 ISS Memory
Interface Periph. COMM2 Interface
Communication Network (Bus/NoC)
d) Virtual Prototype
Figure 2. MPSoC at different abstraction levels
Figure 2 illustrates the MPSoC abstraction levels for a
simplified application made of 3 tasks (T1, T2 and T3), that
are mapped on an architecture made of 2 processing units
and several memory hardware subsystems. Simulation at
each level will be used to validate the software and
hardware components at the corresponding abstraction level.
The main differentiation between these levels is the detail
levels of hardware and software, the way of specifying the
hardware-software interfaces and the communication.
The highest level is called system architecture level
(SA) (figure 2.a). This combines the application with
partitioning and mapping information. The application is
made of a set of functions grouped into tasks. The function
is an abstract view of the behavior of an aspect of the
application. Several tasks may be mapped on the same
processor subsystem. The communication between tasks
mapped on the same subsystem (intra-subsystem) and the
communication between the different subsystems (inter-
subsystem) make use of abstract communication links, e.g.
standard Simulink signals or explicit communication units
that correspond to specific communication paths of the
target platform. The corresponding hardware platform
the final code of tasks and may give useful statistics about
the communication requirements, such as total amount of
Memory HdS API
Comm OS
data exchanged during the execution.
Periph. HAL API The second intermediate level is called transaction
Abstract CPU2
accurate architecture level (TA) (figure 2.c). The tasks code
is linked with an OS and communication library to
implement the communication units and task management
T2 T3
services. The resulting software makes use of hardware
abstraction layer primitives (HAL_API). The data transfers
Periph.
HdS API
Comm OS
use explicit addresses, e.g. read_mem(addr, dst,
HAL API size)/write_mem(addr, src, size). The hardware is a more
HAL
detailed platform which includes the network component
(NoC or bus), the explicit peripherals accessed by the HAL
APIs and an abstract computation model of the processor.
The simulation at this level allows validating the integration
of the application with the OS and the communication layer.
It may also provide precise information about the
communication performances, such as conflicts on the bus
or NoC congestion.
The lowest level is called Virtual Prototype (figure 2.d).
The HAL API and processor are implemented through the
use of a HAL software layer and the corresponding
processor model for each software subsystem. At the virtual
prototype level the communication consists of physical I/Os,
e.g. load/store. The hardware platform is fully detailed with
RTL components for the hardware resources. The
simulation at this level allows performance validation and it
corresponds to classical hardware/software cosimulation
models with Instruction Set Simulators [13] [14] for the
processors.
4. MPSOC DESIGN STEPS
Figure 3 illustrates the main steps of the proposed
MPSoC design flow. This starts with a manual modeling
step to build the hierarchical Simulink model at the System
Architecture level. This input Simulink model captures the
grouping of functions into tasks and the tasks into

SCSC 2007 499 ISBN # 1-56555-316-0

subsystems. The Simulink model may use explicit automatic generation and validation of the software stack,
communication units to abstract the intra-subsystem hardware platform and communication architecture.
communication (between the tasks mapped on the same Examples of software architecture parameters are:
processor) and inter-subsystem communication (between the OSType, which specifies the name of the OS running on the
tasks mapped on different processors). The proposed flow target processor (Linux, Mutek, DwarfOS, eCos),
allows incremental generation and validation of the CommType, which identifies the type of the communication
software, hardware and the communication architecture. At library used during the HdS integration (POSIX APIs, MPI
each step, the flow generates a specific software component [15], read/write [16], etc), SchedulerType to identify the
and a hardware platform that allows debugging the type of the scheduler (preemptive, cooperative) in the case
corresponding software component and exploring the that the OS provides more than one type of schedulers,
communication architecture. SchedulerAlgorithm to define the algorithm used for the
tasks management by the OS (round-robin, priority based)
Application Architecture etc.
Examples of hardware architecture parameters that
• Application modeling
Modeling
• Tasks Mapping information
annotate the System Architecture model are: ResourceType
• Comm. Mapping information
• Appl. Algorithm Validation
which specifies the type of the hardware resource in the case
Simulation
SA Model of a subsystem (CPU-ARM, CPU-DSP, CPU-XTENSA,
I/O) or the storage resource of the communication buffer in
VA • Task Code Generation
Design • Abstract HW Generation • Tasks Code Validation the case of a inter-subsystem communication unit (SRAM,
Deadlock free execution
• Partitioning Validation
register, global memory); MemoryAccessType which
VA Model Simulation • Communication Archit. identifies whether the memory access is performed directly
Number of exchanged bytes
by the processor or by using a DMA (Direct Memory
TA • OS & Comm Integration Access) component, etc.
Design • TLM HW Generation • HdS Integration Validation
• Communication Archit. The Simulink model is used as a reference model for
Simulation
Number of exchanged bytes
Number of conflicts on the bus
debugging the application’s algorithm. In the System
TA Model
Amount of NoC congestion Architecture level, we perform a discrete-time simulation to
VP • HAL Integration
validate the functionality of the application. For the inter-
Design • RTL HW Generation subsystem and intra-subsystem communication units,
• Final SW Binary Validation
• Performance Measurements Simulink use an abstract simulation model for each of these
• Memory Mapping Validation
VP Model Simulation units based on generic Simulink I/Os.

4.2. Virtual Architecture Design and Simulation

Figure 3. MPSoC Design Flow
4.1. System Architecture Design and Simulation
The System Architecture model represents a high level
application model annotated with partitioning and mapping
information. We use Simulink environment to represent this
level. The functional model of the application may be
described using both standard Simulink blocks and user
defined S-functions and represents the application’s
algorithm.
Aspects related to the architecture model (e.g. processing
units or storage resources available in the target hardware
platform) are combined into the application model (i.e.
multiple tasks executed on the processing units), resulting a
combined architecture/application model. Thus, the System
Architecture model expresses parallelism in the target
application through capturing the mapping of the application
functions into tasks and the tasks into subsystems. It makes
also explicit the communication units between the tasks to
abstract the implementation of the communication protocol
used for the data exchange between them.
The System Architecture model is annotated with
software and hardware architecture parameters to allow the
At Virtual Architecture level, the model is described
using SystemC language and is generated according to the
parameters specified in the initial Simulink model.
At this level, the software is refined to tasks C code by
using specific C code generators [17]. Each task is
encapsulated within a SC_THREAD and uses
communication primitives (HdS APIs).
The hardware is refined to a set of abstract SystemC
modules (SC_MODULE) for each subsystem. The
SC_MODULE of the processor includes the tasks modules
that are mapped on the processor and the communication
channels for the intra-subsystem communication between
the tasks inside the same processor. The communication
channels between the tasks mapped on the same processor
are implemented using standard SystemC channels. For the
inter-subsystem communication, the hardware architecture
integrates also the resources addressed explicitly by the HdS
APIs. Typical examples are memories that serve to store the
communication buffers. The interconnection between the
different components uses an abstract model of the
communication network that allows the data transfer from
the source to the destination module.

ISBN # 1-56555-316-0 500 SCSC 2007

 The simulation at the Virtual Architecture level allows
validating the tasks C code of the refined software and the
partitioning. It uses pure SystemC engine for the tasks
scheduling.
The Virtual Architecture simulation also gives
important statistics regarding the communication
requirements, such as the total number of bytes exchanged
between the subsystems during the whole execution of the
application, the amount of data passing through the global
interconnect component, the buffer size requirements in the
worst case scenario for the storage resources in order to
support the communication mapping specified at the System
Architecture level or the amount of read/write operations
performed at the storage modules. Based on the application
requirements and the communication traffic resulted after
the virtual architecture simulation, the designer can fix the
topology of the interconnect component that will be
included in the hardware platform at the next abstraction
level (bus-based topology or NoC based topology).
4.3. Transaction Accurate Architecture Design and
Simulation
The Transaction Accurate Architecture model is
described using SystemC TLM language and is generated
according to the annotated architecture parameters of the
initial Simulink model and the results of the Virtual
Architecture model simulation.
At the Transaction Accurate Architecture level, the
software is composed of task code, an OS, and
communication layer which implements the HdS APIs. The
OS and communication components make use of HAL APIs
to access the hardware resources. The intra-subsystem
communication is managed fully by the OS and
communication libraries. The tasks are scheduled by the OS.
At the Transaction Accurate Architecture level, the
hardware is refined to a more detailed architecture. This
includes the local components of the different subsystems,
such as peripherals, synchronization components, local
memories and network interfaces. The different subsystems
are interconnected by an explicit network communication
component (bus or NoC). During the generation, design
decisions such as NoC size definition, subsystems
positioning over the global interconnect component, NoC
topology, NoC routing algorithm and communication buffer
size are implemented at the Transaction Accurate
Architecture level.
The simulation at the Transaction Accurate
Architecture is based on native software execution and
SystemC simulation for the hardware platform [18]. Each
software stack is a SystemC thread which creates a UNIX
process for the software execution. At the beginning of the
simulation, the SystemC platform launches a GNU standard
debugger (gdb) UNIX process for each software stack in
order to start its execution. The software stack interacts with
SCSC 2007
the corresponding SystemC abstract processor module
through the UNIX IPC layer. The hardware-software
interface uses UNIX shared memory for the interaction
between the software and hardware.
The simulation allows validation of the integration of
the tasks code with the OS and communication libraries. On
the hardware side, it gives more precise statistics on the
communication architecture such as number of conflicts on
the shared global bus due to the simultaneous access
requests in the case of a bus-based architecture topology.
For a NoC based architecture topology, useful information
deduced during the simulation are related to the amount of
NoC congestion, number of routing requests, number of
transmitted packets, the average amount of transmitted
bytes per packet or the number of times some routers failed
to transmit the packed due to the conflicts. For both
topologies (bus and NoC), the Transaction Accurate
Architecture simulation allows extracting the total amount
of transmitted bytes.
4.4. Virtual Prototype Design and Simulation
The Virtual Prototype model is described in SystemC at
RTL level. The software stack is fully explicit, including the
HAL layer to access the hardware resources and it is
detailed to ISA (Instruction Set Architecture) level for a
specific processor.
The hardware architecture incorporates an ISS for each
processor to execute the final binary code.
The simulation performed at this level is cycle accurate.
It allows validating the memory mapping of the target
architecture and the final software code. It also provides
precise performance information such as software execution
time, computation load for the processors, the number of
cycles spent on communication, etc.
5. EXPERIMENTAL RESULTS
To show the efficiency of the proposed MPSoC design
flow, we applied the presented approach onto three real
multimedia applications: a MP3 Decoder, a Motion JPEG
Decoder application and a H.264 Main Profile Encoder.
First, we developed the System Architecture model to
validate the application’s algorithm and to specify the
partitioning and mapping.
As target architecture we used a heterogeneous
architecture based on [19]. The architecture is composed of
an ARM9 processor, an ATMEL DSP subsystem, an I/O
subsystem and a global memory. The communication
between the processors may use different resources for
mapping the data buffers (i.e. local memories of both
processors or global memory). The different subsystems
may be interconnected using different components, such as
an AMBA bus or NoC Mesh or Torus topologies) according
to the application’s requirements.
501 ISBN # 1-56555-316-0
 After the System Architecture model, we refined the To build the H.264 encoder we used as reference C
hardware and the software to the Virtual Architecture level code the x264 open source code. The CABAC part of the
in order to estimate by simulation the total number of the encoding algorithm was mapped on the DSP, while the
exchanged bytes during the execution of the whole other computation and control functions are mapped on the
application. Based on the communication requirements of ARM processor (figure 6). The communication between the
the application, we decided the topology of the global 2 tasks mapped o the processors requires 19 communication
interconnect component and then we refined further the units. The simulation time to encode in Simulink 10 frames
hardware and software to the Transaction Accurate Main Profile QCIF YUV 420 video sequence was 45s.
Architecture level to validate the implementation of the T1
T2
communication protocol and build the software stack. These +
Fn IT Q Reorder CABAC NAL
steps are detailed in the following paragraphs. -

.yuv ME
5.1. System Architecture Simulation F’n-1
Inter
MC
We developed the MPEG-1 Audio (layer 3) decoder Prediction
(shortly the MP3 Decoder) model in Simulink. During this Choose
Intra Pred.
Intra
Pred. Intra
step, the main functions of the MP3 decoder were isolated
into separate tasks (figure 4). Then, we mapped two tasks F’n
+
Filter IT-1 Q-1
(T1 and T3) on the ARM processor and task T2 on the DSP. +

To represent the communication protocol between the tasks, Figure 6. H.264 Encoder algorithm
we inserted 4 communication units: 1 between the 2 tasks
mapped on the ARM and 3 between the processors. The During the experimentation, we attempted different
simulation time in Simulink for an 80KB input MP3 audio communication mapping schemes between the processors.
file was 5s on a PC running at 1.73GHz, 1GMBytes RAM. In the first scheme, the data exchange is made only via the
The simulation allowed validating the application algorithm. global memory. The second communication scheme makes
T1 T2 T3 use of the local memories to store the communication
MP3 Packet Huffman Synthesis PCM buffers. The third case uses both local and global memories
IQ IMDCT
Decoder Decoder Filter bank for the communication (mixed case). In all the situations,
the communication between tasks mapped on the same
Figure 4. MP3 Decoder processor makes use of the software FIFO protocol. In the
following sections, we will consider the worst case scenario,
In the same manner, we built the Motion-JPEG when all the communication buffers are mapped on the
Decoder in Simulink using 7 S-functions and we grouped global memories. Thus, every data exchange between the
them into 3 tasks mapped on the two processors. The processors has to pass minimum two times through the
decoded image is displayed using a LCD panel connected to global interconnect component (the producer writes in the
the I/O Peripherals subsystem (POT). The System global memory, the consumer reads the data from the global
Architecture Model of MJPEG is illustrated in figure 5. It memory).
contains 8 communication units: 5 between the tasks
mapped on the ARM processor and 3 between the different 5.2. Virtual Architecture Simulation
subsystems. The simulation time for a 10 frames input We generated the Virtual Architecture model. The
bitstream encoded using QVGA YUV 444 format was 17s software is composed of C code for the application tasks.
in Simulink. The hardware is composed of three abstract subsystems
comm1
(DSP, ARM and I/O), the global memory and an abstract
comm3
network component, described in SystemC. At this level, the
ARM DSP POT
comm2
software tasks are scheduled by the SystemC simulation
engine.
The simulation at the virtual architecture level allowed
comm4
Task2 Specification gathering of important early performance measurements, e.g.
the amount of data exchanged between the processors, the
comm5
Task1 Task2 buffer size requirements and the amount of read/write
comm6
operations performed at the storage modules.
comm7
Table 1 illustrates the total amount of exchanged bytes
comm8
during the execution of the applications and the simulation
time for the 3 multimedia applications.
Figure 5. Motion JPEG System Architecture in Simulink

ISBN # 1-56555-316-0 502 SCSC 2007

 Table 1. Virtual Architecture simulation results obtain a routing definition. In this simulation, 42.623.519
requests of routing were demanded. The first column of
Application Total bytes Simulation time
Table 2 illustrates the percentage of routing requests at each
MP3 Decoder 3014k ~2s
router, while the other details this information for each
80KB MP3 audio file
router port.
MJPEG Decoder 5256k ~14s The H.264 is the most communication intensive
10 frames QVGA YUV 444 application between the three case studies. In this case, the
H.264 Encoder 2488270k ~4m46s interconnect component between the different subsystems
10 frames QCIF YUV 420 was a NoC similar with the one used for the MJPEG
application, but it implements a Torus topology. In this NoC
5.3. Transaction Accurate Architecture Simulation model, every router has five bidirectional ports to
At the Transaction Accurate level, we used a tiny OS implement a 2D Torus topology with wraparound links at
for the tasks management and an MPI-based semantic for the edges of the network. The routing algorithm is a
the communication APIs. On the hardware side, the deadlock free version of the well known non-minimal west-
architecture is more detailed, including the local peripherals first algorithm proposed in [21]. The total number of the
of each processor subsystem (local memories, local bus, routing requests represents 14410M.
network interface, interrupt controller and mailbox for Table 3 summarizes the simulation time at the
synchronization). The network component becomes explicit Transaction Accurate Architecture level required to execute
based on the communication requirements determined each of the 3 multimedia applications. As transaction
during the Virtual Architecture level simulation. accurate hardware/software architecture contains more
The execution of the MP3 application requires a data details than the Virtual Architecture, the simulation is
exchange for the communication between the processors slower than the Virtual Architecture simulation, but it is
around 3MB. Therefore, an AMBA bus is suitable as more accurate.
interconnect component to assure the required
communication performance. During the simulation of the Table 3. Transaction Accurate Architecture simulation results
MP3 application on the Transaction Accurate Architecture
with AMBA, the global bus was accessed 4366k times and Application Interconnect Simulation time
2489k conflicts were detected due to the simultaneous Component
access requests for the shared global bus. MP3 Decoder AMBA bus ~22s
For the MJPEG Decoder application, the adopted 80KB MP3 audio file
interconnect component at the Transaction Accurate level MJPEG Decoder NoC Mesh ~5m10s
was a Hermes-based NoC [20]. This NoC employs a 2D 10 frames QVGA YUV 444
Mesh topology with 6 routers (3x2). The routers may have H.264 Encoder NoC Torus ~28h10m
from three to five ports, depending on the router position 10 frames QCIF YUV 420
relative to the limits of the mesh. It uses a pure XY routing
algorithm shared by all the ports and a round robin 6. CONCLUSION
scheduler to arbitrate the simultaneous transmission
requests. In this paper we presented a Simulink based MPSoC
Table 2 presents the relative number of routing design flow that allows gradual hardware, software and
requested per each input port in each router that composes communication refinement. The flow starts with a high level
the mesh NoC during the MJPEG simulation. application model described in Simulink. During the
refinement, the presented approach allows mixed hardware-
Table 2. Relative routing requests during the simulation software validation at different abstraction levels in addition
TOTAL LOCAL NORTH SOUTH EAST WEST to opening to new facilities such as communication mapping
0x0 24,0% 11,3% 5,7% 0,0% 7,0% 0,0% exploration and network component refinement. The
0x1 11,4% 2,9% 0,0% 1,3% 7,2% 0,0% efficiency of the proposed flow has been illustrated with 3
1x0 18,3% 0,0% 0,0% 0,0% 7,0% 11,3% case studies using the MP3, Motion JPEG and H.264
1x1 10,1% 0,0% 0,0% 0,0% 7,2% 2,9% multimedia applications and executed on an architecture
2x0 20,0% 7,2% 1,5% 0,0% 0,0% 11,3%
with different interconnect topologies (AMBA, NoC Mesh,
2x1
NoC Torus).
16,1% 7,4% 0,0% 5,8% 0,0% 2,9%

Biography
A routing request is performed at least once when a Katalin Popovici is currently PhD Student in
packet arrives to a router and, depending on the NoC Microelectronics at TIMA Laboratory, National Polytechnic
specification, can request as many times as necessary to Institute of Grenoble, France. She received the Computer

SCSC 2007 503 ISBN # 1-56555-316-0

Science Engineering Degree from Polytechnic University of
Oradea, Romania in 2004. Her current research interests are
architecture/application modeling and simulation for
heterogeneous multiprocessor SoC design running
multimedia applications.
Dr. Ahmed Amine Jerraya received the Engineer degree
from the University of Tunis in 1980 and the D.E.A.,
"Docteur Ingénieur", and the "Docteur d'Etat" degrees from
the University Of Grenoble, France in 1981, 1983, and 1989
respectively, all in computer sciences. In 1986, he held a full
research position with the CNRS (Centre National de la
Recherche Scientifique). From April 1990 to March 1991,
he was a Member of the Scientific Staff at Nortel in Canada,
working on linking system design tools and hardware design
environments. He served as General Chair for DATE 2001.
He also served as a general chair or program chair of several
international workshops and symposia. He organized several
international courses including MPSoC (Multiprocessor
SoC), the pluri-disciplinary summer school. He published
more than 227 papers in International Conferences and
Journals, and 7 books. He received the Best Paper Award at
the 1994 ED&TC for his work on Hardware/Software Co-
simulation.
Dr. Jerraya is currently Head of the design programs at
CEA-LETI, Minatec, Grenoble, France.
References
[1] H. Meyr “Application Specific Processors (ASIP): On
design and implementation Efficiency”, Invited talk of
SASIMI 06, Nagoya, Japan
[2] SystemC, http://www.systemc.org
[3] W.O. Cesario, D. Lyonnard, G. Nicolescu, Y. Paviot,
S.Yoo, L. Gauthier, M. Diaz-Nava, A.A. Jerraya,
“Multiprocessor SoC Platforms: A Component-Based
Design Approach”, IEEE Design & Test of Computers, Vol.
19, Nov-Dec, 2002
[4] Coware, http://www.coware.com
[5] MathWorks Simulink, http://www.mathworks.com
[6] Y. Vanderperren and W. Dehaene, “From UML/SysML
to Matlab/Simulink: Current State and Future Perspectives”,
Proceeding of Design Automation and Test in Europe,
DATE 2006, 6-10 March, Munich, Germany, 93-93
[7] Brian Etscheid, “Enabling the use of an embedded
processor in a Simulink-based design flow”, PhD Thesis,
UC-Berkley, 2001
ISBN # 1-56555-316-0
[8] D. Culler, J.P. Singh, A. Gupta “Parallel Computer
Architecture: A Hardware/Software Approach”, Morgan
Kaufmann, August 1998, ISBN 1558603433.
[9] P. van der Wolf, E. de Kock, T. Henriksson, W. Kruijtzer,
G. Essink “Design and programming of embedded
multiprocessor: an interface-centric approach”, Proceeding of
CODES+ISSS 2004, Stockholm, Sweden, 206-217
[10] Y. Takagi, S. Honda, H. Tomiyama, H. Takada
“Communication interfaces for System Level Design”,
Proceeding of SASIMI 2006, April 3-4, Nagoya, Japan, 21-
28
[11] A. Jerraya, A. Bouchhima, F. Petrot “Programming
models and HW-SW Interfaces abstraction for Multi-
Processor SoC”, Proceeding of DAC 2006, San Francisco,
USA, 280-285
[12] K.Popovici et al. “Efficient Software Development
Platforms for Multimedia Applications at Different
Abstraction Levels”, Proceeding of the 18th IEEE/IFIP
International Workshop on Rapid System Prototyping, RSP
2007, Porto Alegre, Brazil, 113-122
[13] J.A.Rowson “Hardware/Software cosimulation”,
Proceeding of DAC 1994, San Diego, USA, 439-440
[14] L. Semeria, A. Ghosh “Methodology for
hardware/software co-verification in C/C++”, Proceeding of
ASPDAC 2000, Yokohama, Japan, 405-408
[15] MPI, http:/www-unix.mcs.anl.gov/mpi
[16] E.A. de Kock et al. “Yapi: Application modeling for
signal processing systems”, Proceeding of DAC 2000, USA,
402-405
[17] S.-I. Han et al. “Buffer memory optimization for video
codec application modeled in Simulink”, Proceeding of
DAC 2006, San Francisco, USA, 689-694
[18] G.Nicolescu, “Specification et validation des systemes
heterogenes embarques”, PhD Thesis, TIMA Laboratory,
2002
[19] Paolucci, P. et al. “SHAPES: a tiled scalable Software
Hardware Architecture Platform for Embedded Systems”,
Proceeding of CODES-ISSS 2006, 167-172
[20] Moraes, F. et al. “HERMES: an Infrastructure for Low
Area Overhead Packet-switching Networks on Chip
Integration”, Integration, The VLSI Journal, v.38(1), 2004,
69-93
[21] C. Glass, L. Ni “The turn model for adaptive routing”,
Proceedings of the 19th annual international symposium on
Computer architecture, 1992, 278-287
504 SCSC 2007