Multiprocessor system on a chip: Difference between revisions
Content deleted Content added
mNo edit summary |
deleted all content Tags: Replaced Visual edit |
||
| (41 intermediate revisions by 25 users not shown) | |||
| Line 1: | Line 1: | ||
| ⚫ | |||
The '''multiprocessor System-on-Chip (MPSoC)''' is a [[system-on-a-chip]] (SoC) which uses multiple processors (see [[multi-core]]), usually targeted for embedded applications. It is used by platforms that contain multiple, usually heterogeneous, processing elements with specific functionalities reflecting the need of the expected application domain, a memory hierarchy (often using [[scratchpad RAM]] and [[direct memory access|DMA]]) and I/O components. All these components are linked to each other by an [[on-chip interconnect]]. These architectures meet the performance needs of multimedia applications, telecommunication architectures, network security and other application domains while limiting the power consumption through the use of specialised processing elements and architecture. |
|||
==See also== |
|||
*[[Multi-core (computing)]] |
|||
| ⚫ | |||
*[[Many-core processing unit]] |
|||
*[[Multiprocessing]] |
|||
*[[Symmetric multiprocessing]] (SMP) |
|||
*[[Computer multitasking|multitasking]] |
|||
*[[Parallel computing]] |
|||
==External links== |
|||
* [http://www.mpsoc-forum.org/ MPSoC - Annual Conference on MPSoC] |
|||
* [http://www.u-aizu.ac.jp/%7Ebenab/conferences/mcsoc-09/ Annual Symposium] |
|||
In recent years, we are witnessing the dawning of them MPSoC era. In essence, this era is triggered by the need to handle more complex and dynamic applications, while reducing the overall cost and power consumption of embedded platforms. Nevertheless, programming those platforms is not straightforward, mainly due to difficulties in source code parallelization, in data transfer and storage and in run-time resource management. |
|||
In order to tackle the aforementioned MPSoC programming issues and to relieve the embedded software designer as much as possible, the MPSoC research at imec focuses on providing application mapping tools to assist the designer in mapping sequential C code, and on providing run-time management techniques to optimize the allocation of processing and memory resources at run-time. |
|||
This article to be carried out is on the design methodology required to make intelligent decisions about the RUN-TIME multiprocessor –systems-on chip(MP-SoC) management and mapping of dynamic embedded software. However, obtaining experimental evidence of the soundness of the methodology by applying it on actual applications is a major requirement. This evolution, embedded processors become ubiquitous(present every where simultaneously) and a new role for embedded software in contemporary and future Multiple-Processor systems -on-Chip (MP-SoC) is reserved. Next to these programmable components, they contain a large number of memories (DRAM, SRAM, FIFOs, ...) organized in many different ways. Hence there is a need for proper management of all the data and computation in these complex systems. |
|||
The merging of computers, consumer and communication disciplines gives rise to very fast growing markets for personal communication, multi-media and broadband networks, in the information technology (IT) area. Rapid evolution in sub-micron process technology allows ever more complex systems to be mapped on platforms that become integrated on one single chip. Technology advances are however not followed by an increase in design productivity, causing technology to leapfrog the design of IT systems. A consistent system design technology that can cope with such complexity and with the ever- shortening time-to-market requirements is of crucial importance. It should allow mapping these applications cost-efficiently to the target architecture while meeting all real-time, power, and other constraints. Today, a new heterogeneous architectural design paradigm is emerging usually called a 'platform', including one or more programmable components, either general-purpose or DSP processors, cores or ASIPs (application-specific instruction-set processor), augmented with some specialized data paths or co-processors (accelerators). Through this evolution, embedded processors become ubiquitous and a new role for embedded software in contemporary and future Multiple-Processor Systems-on-Chip (MP-SoC) is reserved. Next to these programmable components, they contain a large number of memories (DRAM, SRAM, FIFOs, ...) organized in many different ways. Hence there is a need for proper management of all the data and computation in these complex systems. |
|||
This article includes both methodology and prototype tool design aspects. The short time to market available to realize these designs indeed requires a very high productivity from the part of the designer. The key solution for this problem is writing down the specification of the system at a higher level of abstraction and providing a methodology to refine this specification into an implementation or components that manage the most time consuming aspects of the implementation through an API. The following essential research problems need to be addressed to solve this problem: |
|||
Massive parallelism is needed in order to reach to low power goals. This includes sub-word parallelism, instruction parallelism and coarse multi-processor parallelism. Especially the problem of using sub-word parallelism is not solved in both academia and industry. |
|||
It must be investigated how much of each type of parallelism needs to be exploited for the Ambient Intelligence application domain. Also flexible architectures that can exchange a certain type of parallelism for another can enable a better exploitation. But then the question is raised how to explore the different alternatives without increasing the design time much? |
|||
Careful decisions need to be taken concerning the dynamic data management. It has to be decided what data structures to use to implement the abstract data types, how much memory to allocate for each data structure and how, and how to keep track of free and used memory for each data structure. Also transformations on these dynamic data structures can significantly reduce implementation cost. Higher-level models are needed to explore and transform different data representation alternatives. Initial research has shown the feasibility. The next step is to fit this in the global design flow. |
|||
All the above can be used to steer system-wide trade-offs between power consumption, memory footprint and quality or throughput/latency (within the constraints to be met). Resources are assigned to tasks such that they can meet their (real-time) constraints while minimizing cost (such as energy). These trade-offs have to be partly decided at run-time based as much as possible on design-time preparations and analysis. The current approach is mainly based on a spatial assignment of tasks to resources in the assumption that there are more resources than tasks. The run-time management and the design-time preparations will change drastically when allowing multiple tasks sharing the same resources over time. The challenge is how to use the design-time information appropriately to limit the run-time overhead. Optimized Design flows, Middleware and RTOS components will play a major role in addressing this challenge. |
|||
There is a need to create a run-time management glue layer that is perfectly suited for the MPSoC environment. This component illustrates how an MPSoC-specific run-time management layer is able to alleviate the needs of the MPSoC environment. The (design time) exploration and optimization component starts out by analyzing and profiling the target application together with a set of potential platform properties (e.g. different memory sizes for different memory hierarchy layers, different communication bandwidth, number of PEs, etc.). The result of the design time exploration should be an improved, scalable application (e.g. containing multiple code versions) bundled with a large amount of design time exploration information. The design time information is coded by means of a multi-dimensional Pareto curve. The application itself will be expanded with run-time resource management functionality such as e.g. block transfers to manage the (scratchpad) memory hierarchy. |
|||
The figures related to this articles as linked below: |
|||
http://t0.gstatic.com/images?q=tbn:ANd9GcQpbnoFLsTDTM16mqtoTKsWUv5_il4eNmFNzz0Hg-j8vMfwIi4r |
|||
http://t0.gstatic.com/images?q=tbn:ANd9GcTR1RogyjEv_WsGHtP7zya2k5sP8CBoRthgdffMXRyLLXlbNv7lmQ |
|||
http://t0.gstatic.com/images?q=tbn:ANd9GcTcBtlukh3FRq6MxIhn6Jg68trAgzOsk0NTPtlsK6DUrzF2U7pb |
|||
The run-time platform manager (above figure) takes the improved application and the Pareto curve as input. Consequently, the run-time manager selects an active Pareto point based on the quality requirements (real-time deadlines, energy constraints, etc.) and the available platform resources. The exploration information allows the run-time manager to predictably tune the application performance to the available resources and the user requirements/constraints. |
|||
Once the resources have been assigned, the application itself will be partly responsible for managing these resources. For example, the application is responsible for managing the assigned L2 memory block or to make sure data is copied in a timely fashion from its assigned L2 memory block to its assigned L1 memory block. Although the run-time manager is responsible for handling the application's request for a memory block, the application itself is responsible for managing the allocation of memory resources within that block. This cooperation obviously requires special constructs within the MPSoC run-time manager. |
|||
In addition, it should be possible to perform a Pareto point switch at run-time in order to react to a changing environment (e.g. when a new application is started, when user requirements change, etc.). Here the run-time manager will be responsible for selecting the destination Pareto point and for guiding the Pareto switching. However, deciding when the Pareto switch should occur needs to be decided in cooperation with the application. |
|||
Concretely, the goal of the MPSoC run-time management research activity should be to create RTOS extensions and algorithms that efficiently exploit the presence of design-time application exploration information in order to manage the resources in an MPSoC environment. Hence the research deals with the pareto’s principal that is; the unequal distribution of wealth in his country, observing that twenty percent of the people owned eighty percent of the wealth. There is a management theory floating around at the moment that proposes to interpret Pareto's Principle in such a way as to produce what is called Superstar Management. The theory's supporters claim that since 20 percent of people produce 80 percent of results We should focus limited time on managing only that 20 percent, the superstars. The theory is flawed, as we are discussing here because it overlooks the fact that 80 percent of time should be spent doing what is really important. Helping the good become better is a better use of time than helping the great become terrific. Apply the Pareto Principle to all we do, but use it wisely. |
|||
The MPSoC application mapping tool suite focuses on source code cleaning (CleanC toolset), on parallelization of the sequential code (multi-processor assist (MPA) tool), and on performing scratchpad memory management (memory hierarchy (MH) tool) P17975. The embedded software designer is responsible for providing parallelization hints and fixed MPSoC platform characteristics. |
|||
(i) Pareto point selection: The main question here deals with how to select a Pareto point in the Pareto hyper surface that minimizes the cost (according to some cost function) for a certain required performance and that considers the available platform resources. As the above figure illustrates, run-time management contains two major components: requirements management, dealing with (i) Pareto point selection and Pareto point switching according to the user requirements and (ii) with the actual assignment of the resources. Hence, this raises the question of how the Pareto point selection and the resource assignment algorithm will be linked. Since selecting a Pareto point also means having an amount of available resources, a specific Pareto point can only be chosen if those resources are (i) available and (ii) can be allocated. |
|||
(ii)Run-time Pareto point switching |
|||
The main question in this case is how to efficiently switch between complex Pareto points? There are a set of issues that have to be considered when performing a Pareto switch. Choosing a new Pareto point (also denoted as destination Pareto point) may be dependent on the current point. Making an assessment of the amount of work involved when switching from one Pareto point to another can partly be done at design time by creating a Pareto point switch cost matrix. However, there will be some run-time issues that need to be taken into account: it might be that due to certain run-time conditions (e.g. platform resource allocation status), some destination Pareto points are favored. |
|||
TOOLS TO BE USED: |
|||
(1) PSoC Designer 5.0 : SCypress Semiconductor Corp. has introduced PSoC Designer 5.0, which the company touts as the industry's first and only integrated design environment that includes both code-free and high-level language programming modes in one package. PSoC Designer 5.0 combines the PSoC Express visual embedded system design tool with the full-featured PSoC Designer software to create a new design paradigm. Users can now start projects in a drag-and-drop visual design mode (system-level view) and then move to code-based design in C language (chip-level view) to refine and customize their projects, all from within a single tool. |
|||
(a)System-Level View: A revolutionary drag-and-drop visual embedded system design environment based on PSoC Express. |
|||
(b)Chip-Level View: A powerful and more traditional integrated development environment (IDE) based on PSoC Designer 4.4. |
|||
(c)Hybrid Designs: Start with the system-level visual environment and transition to the powerful chip-level IDE |
|||
CONCLUSION OF THIS ARTICLE: |
|||
The embedded system designer community needs optimization methodologies and techniques, which do not change the input-output functionality of the software applications or the design of the underlying hardware platform. Thus, the increase of software design time, the adherence to international standards and quality requirements forbid designers to change the functionality of the embedded applications in order to achieve optimizations. The customization and subsequent change of the underlying hardware platform for optimization reasons is also very hard, due to the need to use existing successful platforms, to reuse IP (Intellectual Property) blocks and to keep compatibility with previous product versions. Therefore, any proposed optimization methodologies need to take these boundary constraints into account. |
|||
It is essential that these systematic optimizations methodologies are supported by design automation tools, because due to the very complex nature of the source code, it would be impossible to apply them manually in a reasonable time frame. The automation tools should be able to optimize both statically and dynamically allocated data, in order to cope with design-time needs and adapt to run-time memory needs (scalable multimedia input changing at run-time, unpredictable network traffic, etc.) in the most efficient way. Short time-to-market needs demand the development of advanced heuristics within the tools, in order to speed up the optimization process even more. Finally, there is a definite need to deliver trade-offs, based on multi-objective cost functions, to enable product customization at design time and adaptation to even at run-time and thus, to increase its added value. |
|||
IMEC proposes effective solutions for the design of the run time manager, a software layer between the embedded software applications and the hardware platform P16206. The research in this field in IMEC includes both single-processor and heterogeneous MPSoC platforms P12309, P17443. The proposed software layer is able to manage efficiently at run-time the usage of the resources present on the hardware platform by exploiting relevant metadata information, which characterizes the software and hardware aspects of the embedded system D16205. The hardware resources assigned and scheduled are the processing elements, memory space and on-chip interconnect bandwidth. |
|||
At design-time, the run-time manager is customized according to a number of scenarios, which are derived from the software and hardware metadata information. These run-time manager designs are instantiated then only at run-time, if the metadata information that was exploited at the design-time phase is monitored C16601. Effectively, a single worst-case design is avoided by creating these multiple customized designs based on the aforementioned scenarios C16602. In the case that new metadata is monitored at run-time, then the scenarios (and thus the customized run-time manager designs) are not be instantiated and need to be calibrated at run-time. The adaptation will happen according to the new metadata information. |
|||
1.System will reduce the time of the MPSoC by implementing Run-time Application. |
|||
2.System will save the memory block area at run time for multiprocessors. |
|||
3.Reduce the Cost. |
|||
4.The System will order to reach to low power goals. |
|||
5.The application itself will be expanded with run-time resource management functionality such as e.g. block transfers to manage the (scratchpad) memory hierarchy. |
|||
6.System will manage and follow the new heterogeneous platforms like MPSoC . |
|||
7.system will provide the Prototype at RUN-TIME MPSoC. |
|||
8.System will Manage the real-time deadlines, energy constraints, low power consumption, Speed, area, Application Performance, Time to market and manage resources Which all are challenges in Design time MPSoC. |
|||
REFERENCES (PDF & HTML): |
|||
1.www.mnemee.org/objectives.html |
|||
2.www.mpsoc-forum.org/previous/2008/lectures.html |
|||
3.alexandria.tue.nl/extra2/200810570.pdf |
|||
4.dl.acm.org/citation.cfm?id=1815202 |
|||
5.www.artist-embedded.org/.../ArtistDesign.../D12-6-2-Y4_Platform.pdf |
|||
6.hal-supelec.archives-ouvertes.fr/docs/00/65/88/48/.../2011_SoC.pdf |
|||
7.https://lirias.kuleuven.be/bitstream/123456789/307812/1/113.pdf |
|||
8.www.mume-community.com/events-detail.asp?e=57 |
|||
9.home.dei.polimi.it/gpalermo/papers/IETCDT11.pdf |
|||
10.www.imec.be/ScientificReport/SR2008/HTML/1225004.html |
|||
{{compu-hardware-stub}} |
|||
[[Category:Microprocessors]] |
[[Category:Microprocessors]] |
||
[[Category:System on a chip]] |
|||
Latest revision as of 17:26, 15 November 2023
Redirect to: