1 | \begin{figure}\leavevmode\center |
---|
2 | \includegraphics[width=.8\linewidth]{architecture-csg} |
---|
3 | \caption{\label{archi-csg} Software architecture for digital system generation} |
---|
4 | %\end{figure}\begin{figure}\leavevmode\center |
---|
5 | \mbox{}\vspace*{1ex}\\ |
---|
6 | \includegraphics[width=1.0\linewidth]{architecture-hls} |
---|
7 | \caption{\label{archi-hls} Software architecture of hardware accellerator synthesis} |
---|
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 | Figures~\ref{archi-csg}, \ref{archi-hls} and \ref{archi-hpc} |
---|
15 | summarize the software architecture of the COACH framework we will develop. |
---|
16 | In figures, the dotted boxes are the softwares or formats that COACH |
---|
17 | has to provide and to support. |
---|
18 | \parlf |
---|
19 | For the system generation 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 target application and the synthesis parameters. |
---|
22 | The main parameters are the target hardware architectural template |
---|
23 | with its instantiation parameters, the hardware/software mapping of the |
---|
24 | tasks, the FPGA device and design constraints. |
---|
25 | \verb+CSG+ thus requires an architectural template library, an 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 and |
---|
31 | hardware) either \ADDED{ as an IP under IP-XACT to integrate the SoC in larger |
---|
32 | design or} |
---|
33 | as a SystemC simulator (cycla accurate and/or TLM) to prototype and explore quickly the |
---|
34 | design space or as a bitstream\footnote{COACH generates synthesizable VHDL, and |
---|
35 | launch the \xilinx or \altera RTL synthesis tools.} directly downloadable on the |
---|
36 | FPGA device\footnote{Additional partial bitstreams are generated in case of |
---|
37 | dynamic partial reconfiguration}. |
---|
38 | \begin{ADDEDENV} |
---|
39 | \\ |
---|
40 | Furthermore the architecture template and hardware component libraries will be described |
---|
41 | under the IP-XACT specification to make easilier the configuration of \verb+CSG+ to other |
---|
42 | architecture or the enhancement of existing template with IP. |
---|
43 | \end{ADDEDENV}% |
---|
44 | \parlf |
---|
45 | The software architecture for HAS is presented in figure~\ref{archi-hls}. |
---|
46 | The input is a single task of the process network. The HAS tools do not work |
---|
47 | directly on the C++ task description but on an internal format called |
---|
48 | \xcoach generated by a plugin into the GNU C compiler (GCC). |
---|
49 | This will allow on the one hand to insure that all the tools will |
---|
50 | accept the same C++ description and on the other hand make possible |
---|
51 | their chaining. The front-end tools read a \xcoach description and generate |
---|
52 | a new \xcoach description that exibits more parallelism or implement |
---|
53 | specific instructions for ASIP. The back-end tools read an \xcoach |
---|
54 | description and generate an \xcoachplus description. This is an \xcoach |
---|
55 | description annotated with hardware information (scheduling, binding) required by |
---|
56 | the VHDL and systemC drivers. |
---|
57 | Furthermore, the back-end tools uses a macro-cell library (functional and memory |
---|
58 | unit). |
---|
59 | \parlf |
---|
60 | In addition to digital system design, HPC requires a supplementary |
---|
61 | partitioning step presented in figure~\ref{archi-hpc}. The designer |
---|
62 | splits the initial application (tag 1) in two parts: one still on the PC and the |
---|
63 | other running in a FPGA plugged on the PCI/X PC bus. The two parts exchange data |
---|
64 | through communication primitives (tag 2) implemented in a library. |
---|
65 | To evaluate the relevance of the partitioning, the designer can build a |
---|
66 | simulator. Once the partitioning is validated, the design of the FPGA part |
---|
67 | is done through \verb!CSG! (figure~\ref{archi-csg}). |
---|
68 | \parlf |
---|
69 | The project is split into 8 tasks numbered from 1 to 8. They are described |
---|
70 | in short below and in detail in section \ref{task-description}. |
---|
71 | \begin{description} |
---|
72 | \item[Task-1: \textit{Project management}] |
---|
73 | This task relates to the monitoring of the COACH project. |
---|
74 | \item[Task-2: \textit{\Backbone}] This task tackles the fundamental points of the |
---|
75 | project such as the defintion of the COACH inputs and outputs, |
---|
76 | the internal formats (i.e. \xcoach and \xcoachplus) and their associated tools, |
---|
77 | the architectural templates and the design flow. |
---|
78 | \item[Task-3: \textit{System generation}] This task addresses the prototyping and |
---|
79 | the generation of digital system. Apart from HAS that belongs to task 3 |
---|
80 | and 4, its components are those presented figure~\ref{archi-csg} |
---|
81 | (e.g. \verb!CSG!, operating systems). |
---|
82 | \item[Task-4: \textit{HAS front-end}] This task mainly focusses on four functionalities: |
---|
83 | optimization of the memory usage, parallelism enhancement through loop |
---|
84 | transformations, coarse grain parallelization and ASIP generation. |
---|
85 | \item[Task-5: \textit{HAS back-end}] This task groups two functionalities: |
---|
86 | High-Level Synthesis of data dominated description and HLS of control |
---|
87 | dominated description. |
---|
88 | This task contains also the development of a frequency adaptator |
---|
89 | that will allow the coprocessors to respect the processor and the bus |
---|
90 | frequency. |
---|
91 | \item[Task-6: \textit{PC/FPGA communication middleware}] |
---|
92 | This task pools the features dedicated to HPC. These are mainly the |
---|
93 | validation of the partitioning (see figure~\ref{archi-hpc}), the sytem drivers for |
---|
94 | both PC and FPGA-SoC sides, the hardware communication components and |
---|
95 | the support for dynamic partial reconfiguration. |
---|
96 | \item[Task-7: \textit{Industrial demonstrators}] |
---|
97 | This task groups the demonstrators of the COACH project. |
---|
98 | Most of them are industrial applications that will be developped within |
---|
99 | the COACH framework. |
---|
100 | Others consist in integrating the COACH framework as a driver of |
---|
101 | industrial proprietary design tools. |
---|
102 | \item[Task 8: \textit{Dissemination}] |
---|
103 | This task concerns the diffusion of the project results. |
---|
104 | It mainly consists of the production of 4 COACH releases (\verb!T0+12!, \verb!T0+18!, |
---|
105 | \verb!T0+24! and \verb!T0+36!), the publication of a tutorial and user manuals on a WEB site, the publication |
---|
106 | of research papers in international journals and conferences and the organization of workshops and tutorials in |
---|
107 | international conferences. |
---|
108 | \end{description} |
---|
109 | % |
---|
110 | \begin{figure}\leavevmode\center |
---|
111 | %\includegraphics[width=.4\linewidth]{dependence-task} |
---|
112 | \includegraphics[width=0.70\linewidth]{dependence-task-h} |
---|
113 | \caption{\label{dependence-task}Task dependencies} |
---|
114 | \end{figure} |
---|
115 | Figure~\ref{dependence-task} presents the tasks dependencies. |
---|
116 | "$T_N \longrightarrow T_M$" means that $T_N$ impacts the $T_M$. |
---|
117 | The more bold the arrow, the more important is the impact. |
---|
118 | The graph shows: |
---|
119 | \begin{itemize} |
---|
120 | \item Even though $T4$ and $T5$ functionalities are complementary, |
---|
121 | their developments are independent (thanks to the \xcoach internal format). |
---|
122 | \item $T3$ slightly depends on $T4$ and $T5$. Indeed, $T3$ may work |
---|
123 | without $T4$ and $T5$ if targeted digital systems do not include hardware |
---|
124 | accelerators. |
---|
125 | \item $T3$ strongly impacts $T6$ but $T3$ does not depend at all on |
---|
126 | $T6$. Hence demonstrators ($T7$) of embedded system would not be impacted if |
---|
127 | $T6$ would fail. |
---|
128 | \item $T2$ drives all the tasks ($T3$, $T4$, $T5$, $T6$) and is at the heart of |
---|
129 | the COACH project. |
---|
130 | \item The demonstrators developped in $T7$, of course strongly depend on the achievements |
---|
131 | of the previous tasks ($T2$, $T3$, $T4$, $T5$, $T6$). |
---|
132 | \item $T8$ and $T1$ depend on and impact all the other tasks. |
---|
133 | \end{itemize} |
---|
134 | This organisation offers enough robustness to insure the success of the |
---|
135 | project except for the specification task $T2$. |
---|
136 | The only critical task in this chart is $T2$. \label{xcoach-problem} |
---|
137 | However, the partners met |
---|
138 | 12 times (a one-day meeting per month) during the last year: 10 meetings to exchange and work on scientific |
---|
139 | and technical aspects and 2 meetings to prepare the project proposal. This gives us a high degree of confidence |
---|
140 | that $T2$ will be completed in time. |
---|