2. Presentation Goals
• Introduce the fundamentals of HW/SW codesign
• Show benefits of the codesign approach over current
design process
• How codesign concepts are being introduced into
design methodologies
• (Future) What the benefits, how industry and
research groups are attempting
3. Outline
• Introduction
• Trade-Offs in HW/SW Codesign
• A Decade of Hardware/Software Codesign
• Hardware/Software Codesign:
The Past, the Present, and Predicting the Future
• A New Hw/Sw Co-Design Method For Multiprocessor System On
Chip Applications
• Conclusion
• Questions
4. Outline
• Introduction
• Trade-Offs in HW/SW Codesign
• A Decade of Hardware/Software Codesign
• Hardware/Software Codesign:
The Past, the Present, and Predicting the Future
• A New Hw/Sw Co-Design Method For Multiprocessor System On
Chip Applications
• Conclusion
• Questions
5. What is Codesign?
• The meeting of system-level objectives by exploiting the
trade-offs between hardware and software in a system
through their concurrent design.
concurrent development of HW and SW
integrated design
6. The importance of Codesign
▫ Improves design quality, design cycle time, and cost
Reduces integration and test time
▫ Supports growing complexity of embedded systems
▫ Takes advantage of advances in tools and technologies
Processor cores
High-level hardware synthesis capabilities
ASIC development
7. Why is the Codesign needed?
• Most systems today include both dedicated hardware
units and software units
• Programmable processors being used in systems
• Solve dependability issues of systems (with tradeoff
and interplay)
• Reduce the time-to-market frame
• Etc.
8. Codesign Problem
• Specification of the system
• Hardware/Software Partitioning
• Scheduling
• Modeling the hardware/software system during the
design process
9. Codesign Features
• Enables mutual influence of both HW and SW early
in the design cycle
• Enables evaluation of larger design space
• Analyzing different hardware/software partitions
• Enables fast verification
• Faster exploration of the design space
10. Outline
• Introduction
• Trade-Offs in HW/SW Codesign
• A Decade of Hardware/Software Codesign
• Hardware/Software Codesign:
The Past, the Present, and Predicting the Future
• A New Hw/Sw Co-Design Method For Multiprocessor System On
Chip Applications
• Conclusion
• Questions
11. This paper explore a bottom up HW/SW codesign strategy to
investigate trade-offs in time behavior and area.
• A comparison of hardware and software implementations of
low level modules is given.
Benchmarks: gcd, diffeq, ellipticF, case
Develop methods and criteria for the partitioning of such systems
into a hardware part and a software part.
• Levels: hardware, machine language, programming language,
application modules, and whole applications
12. Trade-offs in performance and
complexity are examined by moving
software primitives into
hardware (Figure 1).
Figure 1 Levels of Abstraction
13. Area Time
Hardware Hardware
• A CMOS 2 µm² • Number of cycles
Software Software
• 32 Bit word 139 µm² • Average number of cycles
**active area take into taken per instruction
HW/SW codesign activities are defined a basic comparison restricted to the two
factors: area and time
14.
15. • Area the hardware 1000
times as much as the
software
•Speedup about 30
times is reached by
introducing hardware.
***Improvements in system design moving parts from software to hardware
can only be expected at higher levels.
17. Outline
• Introduction
• Trade-Offs in HW/SW Codesign
• A Decade of Hardware/Software Codesign
• Hardware/Software Codesign:
The Past, the Present, and Predicting the Future
• A New Hw/Sw Co-Design Method For Multiprocessor System On
Chip Applications
• Conclusion
• Questions
18. This paper explains the Codesign moved from an
emerging discipline to mainstream technology for
about a decade.
Codesign is an ideal way to explore the
design space and to create a suitable
platform architecture.
19. Hardware/Software codesign;
Increase the predictability of embedded system design
by providing:
analysis methods
synthesis methods.
21. HW/SW Partitioning
Definition
The process of deciding, for each subsystem, whether the
required functionality is more advantageously implemented in
hardware or software
Goal
To achieve a partition that will give us the required performance
within the overall system requirements (in size, weight, power,
cost, etc.)
22. • First Steps(Partitioning)
Cosyma from the Technical University of
Vulcan from Stanford
Braunschweig
.
Analyze Performance
Hardware Performance Software Performance System Performance
Use high-level synthesis Worst-case execution CPU-ASIC system
techniques to estimate the time
longest path through the
logic.
23. • Maturation
•**Cosimulation
Mixed-level simulation, designers can trade off simulation
performance for accuracy
•The Ptolemy
The execution of software on the CPU is simulated using
a virtual model of the processor hardware
24. • Maturation
•The worst-case execution time problem •Low-power cosynthesis
•The system-performance problem •Developed models and algorithms for
implementing interface protocols
•Hardware cost estimation
•Esterel model to develop the codesign finite
state machine (CFSM), the synchronous
dataflow model
•Developed a synthesis method combinations of
CPUs and ASICs
25. • Moving Into The Mainstream
• Practical design task -- reconfigurable computing (FPGAs)
The platform FPGA seems to be the chip for which cosynthesis was created:
The chip’s internal architecture is exactly what hardware/software partitioning targets.
FPGA requires;
•Identifying an application that maps well onto
it
•interfaces to the system bus must be built
What language is best for describing the input to hardware/software partitioning algorithm
The system on chip (SoC)
26. SoC design is IP(Intellectual Property)-oriented, so designers can use
CPUs, predesigned special-purpose logic, and even FPGA fabrics as
components.
Platform-based design: A platform is a predesigned architecture that designers can
use to build systems for a given range of applications.
***IP block is a reusable unit of logic, cell, or chip layout design
27. • Open Problems
Still working to define and redefine Developing methods to analyze
computational models for jointly new classes of architectures that are
describing hardware and software starting to become common in
systems. embedded systems. (VLIW)
Continues to evaluate algorithms for System-level power management
design-space exploration.
How to evaluate the effect of networks on
Memory systems continue to be chips on codesign.
the subject of research
Expand to include systems built of many
New modeling languages. SoCs (VLSI)
SystemC and SpecC
system-level design languages.
28. Outline
• Introduction
• Trade-Offs in HW/SW Codesign
• A Decade of Hardware/Software Codesign
• Hardware/Software Codesign:
The Past, the Present, and Predicting the Future
• A New Hw/Sw Co-Design Method For Multiprocessor System On
Chip Applications
• Conclusion
• Questions
29. This paper reviews the past, present, and future prospects for hardware/software
codesign, which is used extensively in embedded electronic system products
for automobiles, industrial design automation, avionics, mobile devices,
home appliances, and other products.
Optimize and/or satisfy design
constraints such as cost,
Hardware/software codesign performance, and power of the final
investigates the concurrent design of product
hardware and software components
of complex electronic systems.
Reduce the time-to-market
frame.
30. Our future of expected diminishing technical progress -the life after Moore’s
law- codesign might become even more important for two reasons:
Sale numbers of successful new technical products by
•Tools to design better quality and more reliable systems
•More design time on a careful analysis and exploration of
design options.
31. The major purposes and intentions of
HW/SW codesign
• Co-ordination
To work together on all parts of a system
• Co-ncurrency
To work concurrently instead of starting the firmware and
software development as well as their test only after the hardware
platform is available.
• Co-rrectness
Complex hardware and software require techniques to not only
verify the correctness of each individual subsystem–
coverify(correct interactions after their integration)
• Co-mplexity
Close the well-known design gap to produce correctly working
and highly optimized (e.g., with respect to cost, power,
performance) system implementations.
32. FACETS AND ACHIEVEMENTS OF
MODERN ESL-BASED CODESIGN:
CODESIGN 3.0
(roughly 2005 until today)
System Design Challenges
Heterogeneous SoC technology
Hardware and software complexity
Integration panacea
There must be a way to raise the abstraction level at which designers express their systems
under design, giving birth to the idea of electronic system level (ESL) design as well as ways to
interface and reuse designs across different abstraction levels.
33. Reduction of the Time-to-Market Frame and Design Risks Through the
Concurrent Analysis, Exploration, and Design of Hardware and Software
34. The Double Roof Model of Codesign
Defines the typical top–down design process for
embedded hardware/software systems
Vertical arrows, each representing a
synthesis step
Horizontal arrows indicate the step of
passing information about the implementation
at a certain level directly to the next lower
level of abstraction as an additional
specification information or constraints
The double roof model can be seen as extending the Y-chart by an explicit separation of software and
hardware design.
Model tries not only to put into perspective the system level as a new and important abstraction level for
the design of electronic embedded systems, but also to concatenate existing design abstraction and
synthesis levels for their integration and interplay.
35. Model-Based Versus Language-Based
Specification of Applications and
Platforms
Languages for Hardware, Software, and Codesign
VHDL and SystemVerilog C and C++ SystemC and SpecC
Important Models of Computation for Codesign
FSMs, timed automata, process networks, Petri nets, and data flow
36. Design Space Exploration
Design space exploration (DSE) has
soon started to become a distinguishing element
of codesign technology.
The design space is given by the set of all possible
permutations of allocations, bindings, and schedules.
Any such triple satisfying a certain number of additional
nonfunctional constraints such as on cost, performance,
power, temperature, etc., is called a feasible solution.
System design space exploration, as the name says, is
the task to explore the set of feasible
implementations
1) efficiently and 2) finding not only one of these, but
3) many and also 4) optimal ones.
37. SystemCoDesigner
J. Keinert, M. Streubuhr, T. Schlichter, J. Falk, J. Gladigau, C. Haubelt, J. Teich, and M.
Meredith, SystemCoDesigner :An automatic ESL synthesis approach by design space
exploration and behavioral synthesis for streaming applications
The goal of the
SystemCoDesigner project
is to automatically map
applications written in
SystemC to a
heterogeneous MPSoC
platform
38. CODESIGN 4.0 OR: RESEARCH
PERSPECTIVES FOR THE NEXT
DECADES OF CODESIGN
•Variations and Extensions of Codesign
•Controller/Scheduler Codesign
•Codesign for Dependability of Future
Nanoelectronic Systems
•Codesign of Runtime Adaptive Systems
39. Mission Statements on the Future of Codesign
The Wall of Complexity The Need for Self-Adaptivity
The Wall of Heterogeneity The Need for Cross-Layer Coverification
The Wall of Dependability
40. Outline
• Introduction
• Trade-Offs in HW/SW Codesign
• A Decade of Hardware/Software Codesign
• Hardware/Software Codesign:
The Past, the Present, and Predicting the Future
• A New Hw/Sw Co-Design Method For Multiprocessor System On
Chip Applications
• Conclusion
• Questions
41. NITA Julian, LAZARESCU Vasile , CONSTANTINESCU Rodica
This paper is to simulate the behavior of multiprocessor system on chip.
With virtual platform (OVPSim made by Imperas Company)
they simulated both hardware architectures and running
software applications.
What they used?
ARM7 IP core
MIPS32 IP core
Shared memory
Local memory
BUS for interconnections
Simulated three systems on chip models
42. NITA Julian, LAZARESCU Vasile , CONSTANTINESCU Rodica
INTRODUCTION & BACKGROUND
The hardware projecting of the
systems on chip The integration of an increasingly
number of processing cores on a
The complexity of the present single chip.
algorithms which require a greater
computing power
The improving of the hardware components is unstoppable, taking
into consideration the problem of power consume, the engineers
have to come with a solution. This solution was the multiprocessors.
43. NITA Julian, LAZARESCU Vasile , CONSTANTINESCU Rodica
INTRODUCTION & BACKGROUND
The systems on chip (SoC) :
More hardware components and circuits specialized for satisfying the limits linked to
the physical size
to the power consumption
Integrate:
Digital functions,
Analogical functions,
Mixed signals,
Radio-frequency functions,
The Multiprocessor Systems on Chip (MPSoC):
Systems on chip which integrate more processors, usually created for dedicated
applications.
solves implementing parallelism problem and addressed, elegantly, the problem of the
energy consumption, managing to decrease theclock frequency
44. NITA Julian, LAZARESCU Vasile , CONSTANTINESCU Rodica
HARDWARE-SOFTWARE
CO-DESIGN METHOD
The MPSoC hardware architecture
may be represented asprocessing
nodes or components which
interacts through a network.
A node to be formed of
three layers
45. NITA Julian, LAZARESCU Vasile , CONSTANTINESCU Rodica
HARDWARE-SOFTWARE
CO-DESIGN METHOD
These models take into consideration only the software
component and imply the existence of some software lower
levels and a hardware platform which can implement the
respective model.
46. NITA Julian, LAZARESCU Vasile , CONSTANTINESCU Rodica
R ESULTS OF SIMULATION
The application consists of three major tasks which can be
easily parallelized:
Task1: recursive generating of Fibonacci numbers
Task2: check if the Fibonacci number is prime or not
Task3: calculating the sum from 1 to the respective
Fibonacci number.
48. NITA Julian, LAZARESCU Vasile , CONSTANTINESCU Rodica
3. simulation
For an application the execution time can be optimized by partitioning the
tasks and by mapping them on the proper processors type
49. Outline
• Introduction
• Trade-Offs in HW/SW Codesign
• A Decade of Hardware/Software Codesign
• Hardware/Software Codesign:
The Past, the Present, and Predicting the Future
• A New Hw/Sw Co-Design Method For Multiprocessor System On
Chip Applications
• Conclusion
• Questions
50. Conclusion
Tried to show that the application and knowledge of hardware/software codesign
techniques is a must for all those who want to keep up with the challenges of
more and more complex electronic system designs in the future.
Hardware/Software Codesign is becoming more and more necessary as mixed
implementation systems become both more prevalent and more complex.
This presentation has attempted to present some of the aspects of codesign and
some of the research papers to develop effective codesign techniques.
51. Outline
• Introduction
• Trade-Offs in HW/SW Codesign
• A Decade of Hardware/Software Codesign
• Hardware/Software Codesign:
The Past, the Present, and Predicting the Future
• A New Hw/Sw Co-Design Method For Multiprocessor System On
Chip Applications
• Conclusion
• Questions
The two key concepts involved in codesign are concurrent development of HW and SW, and integrated design.*concurrent: hardware and software developed at the same time on parallel paths**Integrated: interaction between hardware and software development to produce design meeting performance criteria and functional specsCodesign techniques using these two key concepts take advantage of design flexibility to create systems that can meet performance requirements with a shorter design cycle.
The major factor driving the need for hardware/software codesign is the fact that most systems today include both dedicated hardware units and software units executing on microcontrollers or general purpose processors.Etc... The risk of hidden errors or overdesigning or underdesigning may also be reduced Save development time , allow for the fast verification
Hardware/Software PartitioningDefinitionThe process of deciding, for each subsystem, whether the required functionality is more advantageouslyimplemented in hardware or softwareGoalTo achieve a partition that will give us the requiredperformance within the overall system requirements (insize, weight, power, cost, etc.)The codesign problem consists of specifying the system (typically in a behavioral form), in a representation that is suitable for describing either hardware or software, partitioning the system into either hardware or software, scheduling the execution of the system’s tasks to meet any timing constraints, and modeling the system throughout the design process to validate that it meets the original goals and functionality.
Enables evaluation of larger design space through tool interoperability and automation of codesign at abstract design levels
One basic approach can be characterized by identifying and implementing software parts which consume high computing resources (usually time) in hardware [Henk92]. The dual approach seeks to identify complex system parts which are good candidates to be implemented in software [Gupt92].
At each level trade-offs in performance and complexity are examined by moving software primitives (different at each level, e.g. instructions, programing language constructs, functions) into hardware (Figure 1).The assembler level is defined by the instruction set of the processor. Many different instruction sets are known and can be grouped for example into the two categories of RISC- and CISC designs minimizing either execution time per instruction or number of instructions per intended action Reduced Instruction Set Computer Complex Instruction Set ComputersWe chose the well known language “C” for an illustrative analysis. Its more complex constructs can be grouped into four classes: assignment, comparison, call and control. Starting from the software point of view, the implementation of these constructs is examined.Most programming languages allow the structuring of code sequences in procedures and functions (i.e.“modules”). At this level we examined modules defined by source code functions.Software applications may consist of several software modules
The greatest common divisor (gcd) was implemented for four bit, the diffeq and the elliptic filter for 16 bitHere first trade-offs of moving software into hardware can be identified. Considerable time improvements of 4 to 30 times are achievedThe corresponding software implementation allows a common width of 32 bits, while hardware implementations are mostly smaller, tailored to the real problem (4 bits for the gcd, 16 bits for diffeq and ellipticF).
Results seem to point out that control dominated modules are better HW/SW codesign candidatesArea the hardware implementation requires nearly 1000 times as much as the software implementationExecution time of the hardware and software implementation of these module a speedup about 30 times is reached by introducing hardware
Codesign is an ideal way to explore the design space and to create a suitable platform architecture.
Hardware/Software codesign tries to increase the predictability of embedded system design by providing ;analysis methods that tell designers if a system meets its performance, power, and size goals synthesis methods that let researchers and designers rapidly evaluate many potential design methodologies.The CPU and ASIC communicated by shared memory or registers. This architecture let the system allocate computationally intensive tasks to the ASIC, while allocating work less suited to direct hardware implementation to the CPU.
The CPU and ASIC communicated by shared memory or registers. This architecture let the system allocate computationally intensive tasks to the ASIC, while allocating work less suited to direct hardware implementation to the CPU.DefinitionThe process of deciding, for each subsystem, whether the required functionality is more advantageouslyimplemented in hardware or softwareGoalTo achieve a partition that will give us the requiredperformance within the overall system requirements (insize, weight, power, cost, etc.)
In the early years, much focus had been put on tackling the problem of partitioning a given functional specification into hardware and software, hence a problem of bipartitioning. J.Teich [12]The problem to be solved was similarin formulation to a well-known hardware problem—worst-case execution time—but few researchers had studied this aspect of software performance.System Performance Problem : both assumed that the implementation was single-threaded and that the CPU and ASIC worked mutuallyexclusively. Thus, the CPU had to wait in an idle mode for the hardware to complete a function. J.Teich [12]Vulcan: Initially put all the functionality into hardware and moved operations to the CPU to minimize cost.Cosyma: Started with all operations on the CPU and migrated operations to the ASIC to meet the performance goals
Becker, Singh, and Tell developed acosimulator that linked a hardware simulator to executions of application software. The Ptolemy - Simulating signal processing and heterogeneoushardware/software systems. (In cosimulation, the execution of software on the CPU is simulated using a virtual model of the processor hardware or together with the synthesized hardware part of the system design.)Li,Malik, and Wolfe9 developed an implicit path-analysis algorithm that was more efficient than Park and Shaw’s path-enumeration methodYen and Wolf developed a multiprocessor performance algorithm that analyzed the performance of a set of processes (including data dependencies) mapped onto a network of processors.Frank Vahid and Daniel Gajski used incremental hardware cost estimation to reduce the computational cost of analyzing hardware performance.Fornaciari and colleagues developed a modeling system to estimate the power consumption of an embedded system during cosynthesis.Daveau and colleagues developed models and algorithms for implementing interface protocols once the architectural methods had matured.(Inthis area, methods to generate interface circuits from timing diagrams, or Petri nets automatically, were investigated)
Li,Malik, and Wolfe developed an implicit path-analysis algorithm that was more efficient than Park and Shaw’s path-enumeration methodYen and Wolf developed a multiprocessor performance algorithm that analyzed the performance of a set of processes (including data dependencies) mapped onto a network of processors.Frank Vahid and Daniel Gajski used incremental hardware cost estimation to reduce the computational cost of analyzing hardware performance.Fornaciari and colleagues developed a modeling system to estimate the power consumption of an embedded system during cosynthesis.Daveau and colleagues developed models and algorithms for implementing interface protocols once the architectural methods had matured.(Inthis area, methods to generate interface circuits from timing diagrams, or Petri nets automatically, were investigated)
Field-programmable gate arrays (FPGAs)A key problem in CPU/ASIC architectures is the communication between the CPU and the ASIC.On the CPU side, drivers are required to turn software operations into peeks and pokes on the hardware.On the FPGA fabric side, interfaces to thesystem bus must be built. The FPGA fabric and CPU can communicate directly by shared memory.Describe some obvious hardware functions in a hardware description language and describe the rest of the functions in a software language.Because SoCs do not have a fixed architecture, a variety of algorithms for analyzing and synthesizing general architectures are important to SoC cosynthesis.Hardware/software partitioning is now a practical design task, thanks to reconfigurable computing. (FPGAs)
idea and benefits of separately modeling the application and target architecture spread fast in the community and were refined and developed much further under the name of platform-based design (PBD).
Work that includes applying genetic algorithms and other advanced methods to codesign.Since their design profoundly influences the system’s performance as well as its energy consumptionVLIW(very long instruction word) processors, for example, have become popular for signal processing and networking applications.
Sale numbers of successful new technical products will not be driven so much any more by just technological progress, but more and more by tools to design better quality and more reliable systems with a given technology than any competitor
Lack of standards and ways to describe and integrate subsystems developed by potentially other companies and reuse these in order to respect reasonable time-tomarket windows
(a)In the worst case, the firmware and software teams can therefore not start to develop and test their software until the hardware design is available. This also has the great risk of delaying the whole product design chain in case conceptual hardware design errors or production errors are detected late or even only once the software is running on the available prototype.The hardware design decisions are taken based on the experience of a hardware designer team and the progress and success of the software by a software engineering team.• long critical path resulting in long and oftenunpredictable time-to-market frame;• risks for potential errors in each part of the designchain uncovered only very late;• risk for overdesigning or underdesigning a system dueto the missing early evaluation of design options(b)Based on this initial modeling overhead, an early design space exploration of potential solutions in a choice of system components,interconnect, and memory layout as well as the distribution of software functions, and thus design tradeoffs, is possible.
The left-hand side of the roof shows typical abstraction levels encountered during the software design process, whereas the right-hand side corresponds to typical refinement steps during the hardware design process.There is one common level of abstraction: the ESL that has been described above and at which one cannot yet distinguish between hardware andsoftware.The upper roof describes the functional or specification view of the system at the corresponding abstraction level, whereas the lower roof describes its structural implementation, including allocated resources as well as schedule and binding decisions and the corresponding code.
Designing hardware and software separately from each other may lead to underdesigned system implementations not meeting all nonfunctionalproperties such as timing, cost, or power consumption. Alternatively, design decisions for the allocation of resources might have been taken too strictly, leading to too costly and thus overdesigned system implementations and reducing the later win margins per unit sold.Problems:Exploration cost and exploration strategies (algorithms)Multiobjective nature and evaluation of nonfunctional properties (Pareto-Front -- denotes the set of all Pareto-optimal points)How to flexibly evaluate the quality of a design point? (How flexibly different customizable objectives may be specified and evaluated)
In the first step, the designer writes an actor-oriented application model using SystemC. In the second step, different hardware accelerators may be generated automatically for actors in the application model using behavioral synthesis and stored in a component library. This library also contains other synthesizable IP cores such as processors, buses, memories, etc. Before automatically exploring the design space, the designer has to define an MPSoC platform model from resources in the component library as well as mapping constraints for the actors. During DSE, allocations as well as bindings of tasks to processing resources and communications to routes in the architecture are determined and evaluated for objectives such as cost, power, and performance using the concept of user-definable evaluation functions. From the set of nondominated solutions, the designer may then select promising implementations for subsequent rapid prototyping.
Variations and Extensions of Codesign: A cyber-physical system (CPS) is a system featuring a tight combination of, and coordination between, the system’s computational and physical elements*Analog/Digital Codesign**Architecture/Compiler CodesignController/Scheduler Codesign: developing the control application of a plant with its typical objectives of stability, and energy of control together with the often distributed digital system implementation.Codesign for Dependability of FutureNanoelectronic Systems: new techniques will have to be developed on the base of the hardware side of the double roof model to keep the dream of cross-level design automation alive. It is very difficult to predict what models of computation and effects we will face in 50 years from now. Moreover, we believe that in the next 100 years we will definitely see the postsilicon era become a reality, 3-Ddesign become mature, and new principles such as carbon nanotubes as well as single-electron transistor technologies or quantum computers demanding again a completely new rethinking, remastering, or adding of new abstraction levels into the double roof model.Codesign of Runtime Adaptive Systems: Electronic embedded systems will require a certain degree of runtime adaptivity in order to cope with unpredicted and unforeseen situations, the more they become connected and the more they become cyber–physical. Runtime adaptivity may be technically achieved on both software and hardware sides opening the doors to thinking about online techniques for hardware/software codesignthat run in the embedded system itself in order to achieve a situation-aware optimization of the partitioning of hardware and software.
The hardware projecting of the systems on chip and the complexity of the present algorithms which require a greater computing power, all these will lead to the integration of an increasingly number of processing cores on a single chip.The improving of the hardware components is unstoppable, takinginto consideration the problem of power consume, the engineershave to come with a solution. This solution was the multiprocessors. Thus, instead of increasing the clock speed, the designers have chosen the multiplication of the processing cores. (MPSoC)
The field of applicability of these structures is dictated by the increasing needs of computing performance in the same time with restraining the consumption of power.(military, medical supplies, multimedia, telecommunications, automotive.)
The upper layer is the software application which can be multi-threaded or single-threaded. This model uses the parallel programming (Parallel Program Models) in order to abstract the platform on which it exists.Layer 2 contains software which depends on the hardware component (Hardware-Software Dependences). The Hardware-Software Dependences layer is responsible for the management and allocation of resources.Details, such as accessing mode of these resources, are abstracted in the third layer, in which the hardware component is abstracted (Hardware Abstractization Layer).The processing nodes may be SW or HW; the SW nodes are programmable subsystems which include one or more identical processing units.
In order to overcome the stagnation in developing the parallel applications on heterogeneous parallel hardware, the HW/SW co-design seems to work.MPSoC heterogeneous architectures have a real advantage comparing to the standard homogeneous architecture, because they can perform the programmed tasks in a shorter time and also they can perform high complexity tasks.
