Changeset 235 for anr/section-3.2.tex
- Timestamp:
- Feb 16, 2010, 5:03:31 PM (15 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
anr/section-3.2.tex
r182 r235 11 11 \item[HPC setup:] During this step, the user splits the application into 2 parts: the host application 12 12 which remains on a PC and the SoC application which is mapped on the FPGA. 13 The COACH framework will provide a SystemC simulation model of the whole system (PC+communication+FPGA-SoC) which will allow performance evaluation of the partitioning. 13 COACH will allow to automatically translate high level language programs to FPGA configurations. 14 In addition, it will provide a SystemC simulation model of the whole system (PC+communication+FPGA-SoC) 15 which will allow performance evaluation of the partitioning. 14 16 \item[SoC design:] In this phase, 15 the user will be ableto obtain simulators for the SoC at different abstraction levels by giving to the COACH framework a SoC description.16 This description will consist of a process network corresponding to the SoCapplication,17 COACH will allow the user to obtain simulators for the SoC at different abstraction levels by giving to the COACH framework a SoC description. 18 This description will consist of a process network corresponding to the application, 17 19 an OS, an instance of a generic hardware platform 18 and a mapping of processes on the platform components. The supported mapping are20 and a mapping of processes on the platform components. COACH will offer different targets to map the processes: 19 21 software (the process runs on a SoC processor), 20 22 ASIP (the process runs on a SoC processor enhanced with dedicated instructions), 21 23 and hardware (the process runs into a coprocessor that is generated by HLS and plugged on the SoC bus). 22 \item[Application compilation:] Once the SoC description is validated , COACH will generate automatically24 \item[Application compilation:] Once the SoC description is validated through performances analysis, COACH will generate automatically 23 25 an FPGA bitstream containing the hardware platform with the SoC application software and 24 26 an executable containing the host application. The user will be able to launch the application by … … 39 41 40 42 % Detailler les verrous scientifiques et techniques a lever par la realisation du projet. 41 System design is a very complicated task and in this project we will try to simplify it 42 as much as possible. For this purpose we have to deal with the following scientific 43 and technological barriers. 43 System design is a very complex task and in this project we will try to simplify it 44 as much as possible. For this purpose the following scientific and technological barriers 45 have to be addressed. 46 47 \begin{description} 48 \item[Design Space Exploration:] 49 The COACH environment will allow to easily map an application described by using a process 50 network Model of Computation (MoC) on a shared-memory, MPSoC architecture. COACH will 51 allow to explore the design space by allowing system designer to select and 52 parameterize the target architecture, and to define the best hardware/software 53 partitioning of the application. 54 \item[Hardware Accelerators Synthesis (HAS):] 55 COACH will allow the automatic generation of hardware accelerators when required. 56 Hence, High-Level Synthesis (HLS) tools, Application Specific Instruction Processor 57 (ASIP) design environment and source-level transformation tools (loop transformations 58 and memory optimisation) will be provided. 59 This will allow further exploration of the micro-architectural design space. 60 HLS tools are sensitive to the coding style of the input specification and the domain 61 they target (control vs. data dominated). 62 The HLS tools of COACH will support a common language and coding style to avoid 63 re-engineering by the designer. 64 \item[Platform based design:] 65 COACH will handle both \altera and \xilinx FPGA devices. 66 COACH will define architectural templates that can be customized by adding 67 dedicated coprocessors and ASIPs and by fixing template parameters such as 68 the number of embedded processors, the number of sizes of embedded memory banks 69 or the embedded the operating system. 70 However, the specification of the application will be independant of both the 71 architectural template and the target FPGA device. 72 Basically, the 3 following architectural templates will be provided: 73 \begin{enumerate} 74 \item A \mustbecompleted{FIXME :: Neutral est tres pejoratif. Technology inependent, independant, standard ???} Neutral architectural template based on the SoCLib IP core library and the 75 VCI/OCP communication infrastructure. 76 \item An \altera architectural template based on the \altera IP core library, the 77 AVALON system bus and the NIOS processor. 78 \item A \xilinx architectural template based on the Xilinx IP core library, the PLB 79 system bus and the Microblaze processor. 80 \end{enumerate} 81 \item[Hardware/Software communication middleware:] 82 COACH will implement an homogeneous HW/SW communication infrastructure and 83 communication APIs (Application Programming Interface), that will be used for 84 communications between software tasks running on embedded processors and 85 dedicated hardware coprocessors. 86 \end{description} 87 88 89 90 ---------------------------------------------------------------------------------------------- 91 92 44 93 \begin{itemize} 45 94 \item HLS tools are sensitive to the style in which the algorithm is written. … … 83 132 3 architectural templates that are synthesizable and that can be prototyped, 84 133 one design space exploration tool, 85 2 operating systems (DNA/OS and MUTEKH .134 2 operating systems (DNA/OS and MUTEKH). 86 135 \\ 87 136 The framework fonctionality will be demonstrated with the demonstrators 88 137 (see task-7 page~\pageref{task-7}) and the tutorial example (see task-8 89 page~\ref{subtask-tutorial} .138 page~\ref{subtask-tutorial}).
Note: See TracChangeset
for help on using the changeset viewer.