1 | \begin{figure}\leavevmode\center |
---|
2 | \includegraphics[width=.8\linewidth]{architecture-csg} |
---|
3 | \caption{\label{archi-csg} software architecture for embedded system generation} |
---|
4 | %\end{figure}\begin{figure}\leavevmode\center |
---|
5 | \mbox{}\vspace*{1ex}\\ |
---|
6 | \includegraphics[width=.8\linewidth]{architecture-hls} |
---|
7 | \caption{\label{archi-hls} software architecture of HLS} |
---|
8 | %\end{figure}\begin{figure}\leavevmode\center |
---|
9 | \mbox{}\vspace*{1ex}\\ |
---|
10 | \includegraphics[width=.8\linewidth]{architecture-hpc} |
---|
11 | \caption{\label{archi-hpc} software architecture of HPC} |
---|
12 | \end{figure} |
---|
13 | % |
---|
14 | The figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc} |
---|
15 | summarize the software architecture of COACH framework we plan to develop. |
---|
16 | In figures, the dotted boxes are the softwares or formats that COACH |
---|
17 | has to provide or define. |
---|
18 | \vspace*{.75ex}\par |
---|
19 | For the system genration presented figure~\ref{archi-csg}, the conductor is |
---|
20 | the program \verb!CSG! (COACH System Generator). Its inputs are a process |
---|
21 | network and miscellaneaous generation parameters. |
---|
22 | The main parameters are the template of the target hardware architecture |
---|
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 the |
---|
29 | 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 from the |
---|
32 | 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. |
---|
35 | \\ |
---|
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 | \vspace*{.75ex}\par |
---|
47 | The software architecture for HLS is presented figure~\ref{archi-hls}. |
---|
48 | The input is a task of the process network. The HLS tools do not work |
---|
49 | directly on the C++ task description but on an internal format called |
---|
50 | \xcoach generated by a the GNU C compiler (GCC) tainted by a COACH |
---|
51 | driver. This allows on the one hand to insure that all the tools will |
---|
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. |
---|
59 | \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 | \vspace*{.75ex}\par |
---|
63 | The project is splitted into 8 tasks numbered from 0 to 7. |
---|
64 | The first task (task 0) is the project management, the last one (task 7) is |
---|
65 | the dissemination the other task are listed below: |
---|
66 | \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. |
---|
87 | \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. |
---|
97 | \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} |
---|
105 | \end{figure} |
---|