Project topics and materials
Get Complete Project Material File(s) Now! »
Advanced Systembuilder
Advanced Systembuilder [11] is a framework for automated synthesis of H-MPSoCs developed by the universities of Nagoya and Ritsumeikan. The inputs of the tool are: a functional description of the system using processes and channels with System Level Communication Model (SLCM); an architecture template which specifies the architecture with the available hardware components (number of processors, number of hardware accelerators, and the number of types of memories) and how they are assembled; a mapping specification.
These inputs must be manually specified by the designer. From these inputs, Advanced Systembuilder automatically perform several synthesizes: the hardware is generated through behavioral synthesis with the eXCite tool; the software is synthesized as a C code targeting a Real-Time Operating System (RTOS); communication are synthesized as Application Programming Interface (API) in the C code and as hardware components. In addition, two implementation outputs are produced: one is the files for cosimulation and the other one is the implementation files for typical FPGA backend tools such as Altera Quartus or xilinx ISE. These implementations are used to validate and evaluate the performance of the design. To evaluate the performance of the prototype, Advanced Systembuilder seamlessly integrates into the FPGA design non-intrusive hardware memory and process profilers. The former measures the accesses to the memory along with the potential contention that can occur on the bus accessing the memory, and the latter profile the execution and idle time of the processes. With these measurements designers can decide if they are satisfied with the current design or can identify the points that needs improvement in his design (bottlenecks) and thus modify the design accordingly and relaunch a new iteration of Advanced Systembuilder with it. The biggest lack in Advanced Systembuilder is that it does not perform any automated Design Space Exploration since mapping specifications and the hardware description of the system are provided by the designer as inputs. Moreover to evaluate the performance of a design, they whether rely on a slow Cycle-Accurate Byte-Accurate (CABA)simulation with ModelSim or onto an implementation on FPGA which implies a long implementation time. Consequently, exploring several designs is relatively slow: in [11], the evaluation of 24 designs required about five hours, most of it being due to the logic synthesis steps.
PeaCE
PeaCE [16] is a codesign tool for the design of systems for multimedia applications, developed by the CAP laboratory at Seoul National University. It is based on the Ptolemy framework [17], which is used for the design of real-time framework through modeling through extensive use of several models of computation and simulation. It starts from a model of an application using three di↵erent Model of Computation (MoC)s: one based on Synchronous DataFlow, called Synchronous Piggybacked Data Flow (SPDF) for the specification of computing tasks, another based on Finite State Machine (FSM), called flexible FSM (fFSM) for the specification of control task and another one, called task level-model that specifies high-level interactions between tasks. It also requires a set of the available architecture components (processors and IPs) to be used during the exploration step. The functional specification is used to generate a C code for functional simulation. Then for each task, performance measurements are made for each di↵erent processing unit with an ISS. Then the first step of the DSE is launched: it explores the hardware solution, the partitioning and the mapping. Then code is generated for a hardware/software cosimulation in order to get memory traces of the execution. These memory traces are then used during the second phase of the DSE where communication solutions are explored. In [16], only buses are considered as solution, so the DSE decides the number of buses, which bus is linked to which processing element and memory, bus frequency, etc. Finally, when a solution that satisfies the constraints has been found, implementation codes are generated for simulation tools and FPGA prototyping. The advantages that PeaCE uses a model-driven approach to specify the input application by using and extending MoCs from the Ptolemy project, is also a limitation since designers have to learn how to model their applications with these three di↵erent MoCs instead of simply providing a C code, which is a widespread and well-known language among software designers. Moreover no exploration of the hardware acceleration is performed.
Xilinx XPS
Xilinx Platform Studio (XPS) [18] is a commercial design tool for systems targeting Xilinx FPGA devices. The design of the system can be made through the use of Graphical User Interface in order to add, remove and configure the elements of the hardware platform. It also provides several wizards to assist the designer in the creation of its system. It provides a library of proprietary IPs for the available bus and communication protocols, exploiting the board external peripherals. It also helps to integrate custom IP, through wizards and generation of interfaces in Hardware Description Language for integrating IP. The designed hardware can then be automatically transformed into a bitstream for the target FPGA through syntheses, mapping and placing and routing. Although Xilinx recommends to use Xilinx Software Development Kit (SDK), a customization of the Eclipse framework, for managing the software aspect of the system, it is also possible to fully handle software project from XPS. This includes the compilation of the code as well as the specification of the drivers and the memory mapping. While this tool, along with other Xilinx design tools, simplifies FPGA designs, it still remains a tool difficult to master and its numerous configuration options can often lead to bugs that can be hard to found/traced back at a later stage. The long synthesis times involved or the provided CABA simulation tool, ModelSim, do not allow to test quickly several designs and thus do not provide an adapted environment for design space exploration. So as such it should be used as a backend tool for implementation only.
Space CoDesign
Space Codesign [19] is a a commercial tool developed by SpaceStudio. Starting from an application specified in C code and split into tasks in order to express its parallelism and ease the mapping. Then the architecture must be described through a Graphical User Interface, this includes the number and types of processor, memories, buses along with the partitioning and mapping. Once the architecture specified, the architecture is estimated with the following criteria: performances, logic resources cost and power con- sumption. This is done by generating SystemC TLM virtual platform of the hardware components and the C/C++ code of the software elements (tasks, RTOS). The generated virtual platforms includes non-intrusive profiling component for performances.
The final design is selected based on the quality of results constraints provided by the designer and the corresponding hardware platform can be generated by another tool of SpaceStudio called GenX. The limitation of Space Codesign is that, in spite of its GUI that allows to quickly modify the architecture and the partitioning, it does not perform any automated exploration.
High-Level Synthesis Tools
In H-MPSoC, hardware accelerators are used as a mean to speedup the system and it is part of the design space exploration to decide whether or not part of an application will be accelerated through hardware. If no o↵-the-shelf accelerator is available to the designer, it is possible to generate an IP through the use of HLS tool. It thus can be used as a tool in the ideal flow for H-MPSoC by providing synthesized on-the-fly hardware IP. In this section we present a few of the existing HLS tools.
Gaut
GAUT [20] is a high-level synthesis tool that can generate hardware accelerators from a behavioral C/C++ specification. It has been being developed for 15 years at ENSSAT Lannion and the Universit´e de Bretagne-Sud Lab-STICC laboratory. The synthesis is performed under a time constraint according to: a generic architecture model as illustrated by Figure 2.7; a library of pre-characterized Functional Units (FU), i.e. basic operators such as adders, multipliers and hierarchically designed IPs; and a communication interface choice: FIFO or Ping-Pong memory.
Table of contents :
Contents
1 Introduction
1.1 Contributions
1.2 Outline
2 State of the Art
2.1 Ideal ESL Framework
2.2 Existing MPSoC Design Tools
2.2.1 Daedalus
2.2.2 SystemCoDesigner
2.2.3 Advanced Systembuilder
2.2.4 hArtes
2.2.5 PeaCE
2.2.6 Xilinx XPS
2.2.7 Space CoDesign
2.2.8 Conclusion
2.3 High-Level Synthesis Tools
2.3.1 Gaut
2.3.2 LegUp
2.3.3 C2H
2.3.4 CyberWorkBench (CWB)
2.3.5 Bambu
2.3.6 AutoESL’s AutoPilot
2.3.7 Conclusion
2.4 MDE-based Design of MPSoC
2.4.1 Model Driven Engineering for MPSoC DSE
2.4.2 Multilevel MPSoC Simulation using an MDE Approach
2.4.3 A Co-design Approach for Embedded System Modeling and Code Generation with UML and MARTE
2.4.4 Conclusion
3 Flow of the Framework
3.1 Flow Global Overview
3.1.1 Tool Implementation
3.1.2 Target Architecture
3.1.3 Inputs
3.1.4 Flow Overview
3.1.5 Automated Profiling
3.2 External Tools
3.2.1 HLS Tool
3.2.2 Daedalus
3.2.3 Xilinx XPS
3.3 Database-based Strategy
3.3.1 Template Architecture Database
3.3.2 Hardware Accelerators Database
3.3.3 FPGA Model Database
3.3.4 Reuse-based Strategy
3.4 Conclusion
4 Design Space Exploration Methodology
4.1 DSE Algorithm
4.1.1 Algorithm
4.1.2 Explanations
4.2 Performance & Cost Estimation
4.3 Hardware Accelerators Exploration
4.3.1 HLS-based Estimations
4.3.2 Pareto-optimal Selection
4.4 Data Parallelism Exploration through Task Duplication
4.5 Communication & Memory Model
4.5.1 Congestion Detection
4.6 Data-Task Mapping & Scheduling Strategy
4.6.1 Data Mapping
4.6.2 Task Mapping
4.6.3 Scheduling
4.7 Conclusion
5 Template-based Approach
5.1 Introduction to MDE
5.2 Application to FPGA-based Design
5.3 AADL
5.3.1 Eclipse Modeling Framework
5.4 Component Models
5.5 Specification Template
5.5.1 Template Configuration Interface
5.6 Code Generation
5.6.1 Software Application Adaptation
5.6.2 Implementation Project Files
5.7 Conclusion
6 Results
6.1 Application 1: MJPEG decoder
6.1.1 Presentation
6.1.2 Specifications
6.1.3 Results
6.2 Hardware Accelerators Exploration
6.2.1 IDCT IP Exploration
6.2.2 Benchmark
6.3 Application 2: Face detection with the Viola-Jones algorithm
6.3.1 Presentation
6.3.2 Specifications
6.3.3 Results
6.4 Conclusion
7 Conclusion
7.1 Summary
7.2 Perspectives
8 Bibliography
