Changeset 21 for anr/section-4.1.tex
- Timestamp:
- Dec 31, 2009, 8:27:21 AM (15 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
anr/section-4.1.tex
r12 r21 1 1 \begin{figure}\leavevmode\center 2 2 \includegraphics[width=.8\linewidth]{architecture-csg} 3 \caption{\label{archi-csg} software architecture for embeddedsystem generation}3 \caption{\label{archi-csg} software architecture for digital system generation} 4 4 %\end{figure}\begin{figure}\leavevmode\center 5 5 \mbox{}\vspace*{1ex}\\ 6 \includegraphics[width= .8\linewidth]{architecture-hls}7 \caption{\label{archi-hls} software architecture of HLS}6 \includegraphics[width=1.0\linewidth]{architecture-hls} 7 \caption{\label{archi-hls} software architecture of hardware accellerator synthesis} 8 8 %\end{figure}\begin{figure}\leavevmode\center 9 9 \mbox{}\vspace*{1ex}\\ … … 15 15 summarize the software architecture of COACH framework we plan to develop. 16 16 In figures, the dotted boxes are the softwares or formats that COACH 17 has to provide or define.17 has to provide. 18 18 \vspace*{.75ex}\par 19 For the system genration presented figure~\ref{archi-csg}, the conductor is20 the program\verb!CSG! (COACH System Generator). Its inputs are a process21 network and miscellaneaous generationparameters.22 The main parameters are the t emplate of the target hardware architecture19 For the system genration presented in figure~\ref{archi-csg}, the conductor 20 is the tool \verb!CSG! (COACH System Generator). Its inputs are a process 21 network describing the application to design and the synthesis parameters. 22 The main parameters are the target hardware architectural template 23 23 with its instanciation parameters, the hardware/software mapping of the 24 tasks and the FPGA device.25 From these inputs \verb!CSG! can generate the system (software \& hardware) as 26 a SystemC simulator to prototype and explore quickly the system design 27 space and/or as a bitstream directly downloadable on the FPGA device.28 For processing, \verb+CSG+ requires 1) a hardware template found into the29 architecture library, 2) a micro-kernel, it chooses among 30 two in the micro kernel library, 3) the system hardware components that 31 are taken from the SystemC model library for the simulator and fromthe32 VHDL component library for the FPGA bitstream. 33 For generating the coprocessor of a task mapped as harware, \verb+CSG+ 34 controls the HLS tools described below.24 tasks, the FPGA device and design constraints. 25 \verb+CSG+ thus requires an architectural template library, a operating system 26 library, two system hardware component (CPU, memories, BUS...) libraries 27 (one for synthesis, one for simulation). 28 For generating the coprocessor of a task mapped as hardware, \verb+CSG+ 29 controls the HAS tools described below. 30 From these inputs \verb!CSG! can generate the entire system (both software \& 31 hardware) either as a SystemC simulator to prototype and explore quickly the 32 design space or as a bitstream\footnote{COACH generates synthesizable VHDL, and 33 launch the Xilinx or Altera RTL synthesis tools.} directly downloadable on the 34 FPGA device. 35 35 \\ 36 To proove CSG that COACH is open and CSG is really configurable, COACH will37 basically support 3 architecture template (the COACH template based on a38 MIPS processors and a VCI token ring, the Altera template based on the NIOS39 and AVALON bus, the Xilinx template based on the MICROBLAZE and OPB bus)40 and 2 operating systems (DNA/OS and MUTEK). Furthermore, thus is enforced41 by the \mustbecompleted{FIXME:zied} contribution that consists in42 implementing an other hardware target.43 \\44 Finally, it is important to notice that this work is a strong45 enhancement of the SocLib software.36 %To proove CSG that COACH is open and CSG is really configurable, COACH will 37 %basically support 3 architecture template (the COACH template based on a 38 %MIPS processors and a VCI token ring, the Altera template based on the NIOS 39 %and AVALON bus, the Xilinx template based on the MICROBLAZE and OPB bus) 40 %and 2 operating systems (DNA/OS and MUTEK). Furthermore, thus is enforced 41 %by the \mustbecompleted{FIXME:zied} contribution that consists in 42 %implementing an other hardware target. 43 %\\ 44 %Finally, it is important to notice that this work is a strong 45 %enhancement of the SocLib software. 46 46 \vspace*{.75ex}\par 47 The software architecture for H LS is presentedfigure~\ref{archi-hls}.48 The input is a task of the process network. The HLS tools do not work47 The software architecture for HAS is presented in figure~\ref{archi-hls}. 48 The input is a single task of the process network. The HAS tools do not work 49 49 directly on the C++ task description but on an internal format called 50 50 \xcoach generated by a the GNU C compiler (GCC) tainted by a COACH 51 51 driver. This allows on the one hand to insure that all the tools will 52 52 accept the same C++ description and on the other hand to make possible 53 to chain them. The front-end tools read a \xcoach description and writes 54 a new \xcoach description that exibits possible parallelism or implement 55 specific instruction for ASIP. The back-end tools read a \xcoach 56 description and generates a \xcoach+ description that is a \xcoach 57 description anotated with hardware information to let work the VHDL systemC 58 drivers. Furthermore, the back-end tools uses a macro-cell library. 53 their chaining. The front-end tools read a \xcoach description and generate 54 a new \xcoach description that exibits more parallelism or implement 55 specific instructions for ASIP. The back-end tools read a \xcoach 56 description and generate a \xcoachplus description. This is a \xcoach 57 description anotated with hardware information (scheduling, binding) required by 58 the VHDL and systemC drivers. 59 Furthermore, the back-end tools uses a macro-cell library (functional and memory 60 unit). 59 61 \vspace*{.75ex}\par 60 The software architecture for HPC is presented figure~\ref{archi-hpc}. 61 \mustbecompleted{FIXME Miss HPC description\\\ldots\\\ldots\\\ldots\\\ldots.} 62 In addition to digital system design, HPC requires a supplementary 63 partitioning step presented in figure~\ref{archi-hpc}. The designer 64 splits the initial application (tag 1) in two parts: one still on the PC and the 65 other running in a FPGA plugged on the PCI/X PC bus. The two parts exchange data 66 through communication primitives (tag 2) implemented in a library. 67 To evaluate if the relevance of the partitioning, the designer can build a 68 simulator. Once the partitioning is validated, the design of the FPGA part 69 is done through \verb!CSG! (figure~\ref{archi-csg}). 62 70 \vspace*{.75ex}\par 63 71 The project is splitted into 8 tasks numbered from 0 to 7. … … 65 73 the dissemination the other task are listed below: 66 74 \begin{enumerate} 67 \item\textbf{\backbone:} This task groups the critical issues of the 68 project. They consist of the definition of COACH inputs, the \xcoach 69 format that is mandatory to develop the HLS tools and the HLS drivers 70 that are mandatory for testing the HLS tools. 71 \item\textbf{system generation:} This task groups \verb+CSG+s and the components 72 required to generate the system simulator and bitstream except the HLS 73 tools that belong to the task 3 and 4. These components are the 74 operating systems, the VHDL description and SystemC models of the 75 target hardware achitectures. 76 \item\textbf{HLS front-end:} This task groups the 4 HLS front-head. Those 77 are a tool that exhibits fine grain parallelism using polyedric 78 transformation, a tool that exhibits coarse grain parallelism, 79 a tool that minimizes the memory usage and a tool that implement ASIP. 80 \item\textbf{HLS back-end:} This task groups two HLS back-end tool, one 81 for treating the data oriented description, the second for treating the 82 control dominated description. This task contains also a the 83 development of a frequency adaptator that will allow the coprocessor 84 to respect the processor \& bus frequency. 85 \item\textbf{Communication software PC/FPGA-SoC:} This task groups all what is mandatorythe critical issues of the 86 \item\textbf{Demonstrator:} This task groups the demostrators of the COACH project. 75 \item\textbf{\backbone:} This task tackles the fundamental points of the 76 project such as the defintion of the COACH inputs and outputs, 77 the internal formats (e.g. \xcoach), the architectural templates and 78 the design flow. 79 \item\textbf{system generation:} This task addresses the prototyping and 80 the generation of digital system. Apart from HAS that belong to the task 3 81 and 4, its components are those presented figure~\ref{archi-csg} 82 (e.g. \verb!CSG!, operating systems). 83 \item\textbf{HAS front-end:} This task mainly focusses on four functionalities: 84 optimization of the memory usage, parallelism enhancement through loop 85 transformations, coarse grain parallelization and ASIP generation. 86 \item\textbf{HAS back-end:} This task groups two functionalities: 87 High-Level Synthesis of data dominated description and HLS of control 88 dominated description. 89 This task contains also the development of a frequency adaptator 90 that will allow the coprocessors to respect the processor \& the bus 91 frequency. 92 \item\textbf{Communication between PC \& FPGA-SoC:} 93 This task pools the features dedicated to HPC. The main are the 94 partitioning validation (see figure~\ref{archi-hpc}, the sytem drivers for 95 both PC and FPGA-SoC sides, the hardware communication components. 96 \item\textbf{Demonstrator:} 97 This task groups the demostrators of the COACH project. 98 \mustbecompleted{FIXME} 87 99 \end{enumerate} 88 This task division offers the avantage that tasks except for the "\backbone" and 89 "demonstrator" task are almost independent at the development level as shown 90 figure~\ref{dependence-dev}. The dependence at the validation level is 91 presented figure~\ref{dependence-test}. It is more critical but the 92 redundance in the tasks "HLS front-end", "HLS back-end" and "demonstrators" 93 reduces this inter-dependence.\\ 94 So if the first phasis of "\backbone" task is sucessfully conduced, most of the 95 projet delivrables will be carry through, even if some delivrable are lated 96 or missing. 100 % 97 101 \begin{figure}\leavevmode\center 98 \begin{minipage}[t]{.4\linewidth} 99 \includegraphics[width=1\linewidth]{dependence-dev} 100 \caption{\label{dependence-dev}Dependence graph at development level} 101 \end{minipage}\hfill\begin{minipage}[t]{.4\linewidth} 102 \includegraphics[width=1\linewidth]{dependence-test} 103 \caption{\label{dependence-test}Dependence graph at validation level} 104 \end{minipage} 102 %\includegraphics[width=.4\linewidth]{dependence-task} 103 \includegraphics[width=0.70\linewidth]{dependence-task-h} 104 \caption{\label{dependence-task}Task dependencies} 105 105 \end{figure} 106 Figure~\ref{dependence-task} presents the dependencies between the tasks. 107 "$task-N \longrightarrow task-M$" means that $task-N$ requires $task-M$ 108 to work and be demonstrated. The more bold is the arrow, the more important is 109 the dependency. 110 The graph shows: 111 \begin{itemize} 112 \item Even that $T3$ and $T4$ functionalities are complementary, their 113 developments are independent (thanks to \xcoach internal format). 114 \item $T2$ depends slightly from $T3$ and $T4$. Indeed, $T2$ may works 115 without $T3$ and $T4$ if we limit to digital systems without hardware 116 accellerators. 117 \item $T5$ strongly depends on $T2$ but, $T2$ does not depend at all on 118 $T5$. So demonstrators ($T6$) of embedded system would not be impacted if 119 $T5$ would fail. 120 \item $T1$ drives all the tasks ($T2$, $T3$, $T4$, $T5$) at the heart of 121 the COACH project. 122 \item $T7$ and $T0$ respectively depends on and impacts all the other tasks. 123 \end{itemize} 124 So this organisation offers enough robustness for insure the success of the 125 project except for the specification task $T1$. However, the partners meet 126 10 times (a one day meeting per month) during the last years to prepare the 127 specification and the project proposal.
Note: See TracChangeset
for help on using the changeset viewer.