![R. Gupta[93]](https://image.slidesharecdn.com/hardwaresoftwarecodesign-130123203539-phpapp02/85/Hardware-Software-Codesign-16-320.jpg)
More Related Content
Similar to Hardware Software Codesign
Hardware Software Codesign
- 1. HARDWARE/SOFTWARE CODESIGN CENG-6534 Digital Systems Synthesisand Optimization Summer 2012
- 2. Presentation Goals • Introducethe 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-Offsin 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-Offsin 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 ofCodesign ▫ 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 theCodesign 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 • Enablesmutual 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-Offsin 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 explorea 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 performanceand 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
- 15. • Area thehardware 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.
- 16.
- 17. Outline • Introduction • Trade-Offsin 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 explainsthe 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.
- 20. HW/SW partitioning maps Toachieve a partition that will give us the required performance
- 21. HW/SW Partitioning Definition The processof 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-caseexecution 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 IntoThe 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 isIP(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 Stillworking 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-Offsin 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 reviewsthe 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 ofexpected 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 purposesand 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 ACHIEVEMENTSOF 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 theTime-to-Market Frame and Design Risks Through the Concurrent Analysis, Exploration, and Design of Hardware and Software
- 34. The Double RoofModel 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 onthe 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-Offsin 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, LAZARESCUVasile , 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, LAZARESCUVasile , 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, LAZARESCUVasile , 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, LAZARESCUVasile , 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, LAZARESCUVasile , 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, LAZARESCUVasile , 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.
- 47. NITA Julian, LAZARESCUVasile , CONSTANTINESCU Rodica 1. simulation 2. simulation
- 48. NITA Julian, LAZARESCUVasile , 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-Offsin 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 showthat 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-Offsin 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
- 52.
Editor's Notes
- #6 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.
- #8 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
- #9 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.
- #10 Enables evaluation of larger design space through tool interoperability and automation of codesign at abstract design levels
- #12 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].
- #13 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
- #15 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).
- #16 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
- #19 Codesign is an ideal way to explore the design space and to create a suitable platform architecture.
- #20 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.
- #21 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.)
- #23 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
- #24 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)
- #25 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)
- #26 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)
- #27 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).
- #28 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.
- #31 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
- #33 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
- #34 (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.
- #35 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.
- #37 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)
- #38 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.
- #39 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.
- #43 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)
- #44 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.)
- #45 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.
- #48 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.