[99] | 1 | Embedded systems (SoC and MPSoC) became an inevitable evolution in microelectronic industry. |
---|
[97] | 2 | Due to the exploding fabrication costs, the ASIC technology (Application Specific Integrated Circuit) |
---|
[99] | 3 | is not an option for SMEs (Small and Medium Enterprises). |
---|
| 4 | Fortunately, the new FPGA (Field Programmable Gate Array) components, |
---|
| 5 | such as the Virtex5 family from \xilinx, or the Stratix4 family from \altera can implement a complete |
---|
| 6 | multi-processor architecture on a single device. |
---|
| 7 | But the design of embedded system is a long and complex task that requires expertise in software, |
---|
| 8 | software/hardware partionning, operating system, hardware design, VHDL/Verilog modeling. |
---|
| 9 | Only very few SMEs have these multiple expertises and are present on the embedded system market. |
---|
| 10 | \begin{center}\begin{minipage}{.8\linewidth}\textit{ |
---|
| 11 | The major objective of COACH is to provide to SMEs an open-source framework to design |
---|
| 12 | embedded systems on FPGA devices. |
---|
| 13 | }\end{minipage}\end{center} |
---|
[97] | 14 | %Current design methodologies provide quite low-level abstraction capabilities, and |
---|
| 15 | %there is an urgent need to leverage system level exploration through the use of a high-level |
---|
| 16 | %specification of the application and design space exploration tools. |
---|
| 17 | %The first system oriented approaches are appearing, among which those |
---|
| 18 | %based on C/C++ and SystemC are the most popular, but few of them are specifically targetting FPGAs. |
---|
[99] | 19 | %%% |
---|
| 20 | \parlf |
---|
[97] | 21 | The COACH project will leverage on the expertise gained in the field of virtual prototyping |
---|
| 22 | with the SoCLib platform, to propose a new design flow based on a small number of architectural templates. |
---|
| 23 | An architectural template is a generic, parametrized architecture, relying on a predefined library |
---|
| 24 | of IP cores. |
---|
| 25 | Besides using a specific collection of general purpose IP cores (such as processors cores, |
---|
| 26 | embedded memory controllers, system bus controllers, I/O and peripheral controllers), each architectural |
---|
| 27 | template can be enriched by dedicated hardware coprocessors, obtained by high level synthesis (HLS) tools. |
---|
| 28 | During this project, the COACH partners will develop three different architectural templates: |
---|
| 29 | \begin{enumerate} |
---|
| 30 | \item An \altera architectural template based on the \altera IP core library and the AVALON system bus. |
---|
[99] | 31 | \item A \xilinx architectural template based on the \xilinx IP core library and the PLB system bus. |
---|
| 32 | \item A Neutral architectural template based on the SoCLib IP core library and the VCI/OCP |
---|
| 33 | communication infrastructure. |
---|
[97] | 34 | \end{enumerate} |
---|
| 35 | The proposed design flow starts from a high level description of the application, specified as a set of |
---|
| 36 | parallel tasks written in C, without any assumption on the hardware or software implementation |
---|
| 37 | of these tasks. It let the system |
---|
[99] | 38 | designer in charge of expressing the coarse grain parallelism of the application, gives the designer |
---|
[97] | 39 | the possibility to explore various mapping of the application on the selected template architecture, |
---|
| 40 | and offers a high predictability of results with respect to cost and performance objectives. |
---|
[99] | 41 | \\ |
---|
[97] | 42 | When this interactive, system level, design space exploration is completed (converging to |
---|
| 43 | a specific mapping on a specific version of the selected architectural template), the rest of the flow |
---|
| 44 | is fully automated: The synthesisable VHDL models for the various hardware components, as well as the binary |
---|
| 45 | code for the software running on the embedded processors, and the bit-stream to program the the target FPGA |
---|
| 46 | will be automatically generated by the COACH tools. |
---|
[99] | 47 | % |
---|
| 48 | \parlf |
---|
[97] | 49 | The strength of the COACH approach is the strong integration of the high-level synthesis tools |
---|
| 50 | in a plat-form based design flow supporting virtual prototyping and design space exploration. |
---|
| 51 | Most building blocks already exist (resulting from previous projects): the GAUT |
---|
[134] | 52 | or UGH synthesis tools, the MUTEKH or DNA embedded operating systems, the ASIP technology, |
---|
[97] | 53 | the DSX exploration tool, the MWMR hardware/software communication middleware, the BEE parallelisation tool, |
---|
| 54 | as well as the SoCLib library of systemC simulation models. They must now be integrated in |
---|
| 55 | a consistent design flow. |
---|
| 56 | %The five academic laboratories worked very closely during more than one year (one monthly meeting |
---|
| 57 | %in Paris from january 2009 to february 2010, to analyse the issues of interfacing and integrating |
---|
| 58 | %those various technologies, and to define the detailed architecture of the proposed design flow. |
---|
[99] | 59 | %%% |
---|
| 60 | \parlf |
---|
| 61 | In HPC (High Performance Computing), the kind of targeted application is an existing one |
---|
| 62 | running on a PC. |
---|
| 63 | The COACH framework helps designer to accelerate it by migrating critical parts into a |
---|
| 64 | SoC embedded into an FPGA device plugged to the PC PCI/X bus. |
---|
| 65 | \begin{center}\begin{minipage}{.8\linewidth}\textit{ |
---|
| 66 | The second objective of COACH is to extend the framework to HPC. |
---|
| 67 | }\end{minipage}\end{center} |
---|
| 68 | This will allow SMEs to enter HPC market for the applications that are |
---|
| 69 | unadapted to the current GPU based solutions. |
---|
| 70 | %%% |
---|
| 71 | \parlf |
---|
[97] | 72 | In summary, the COACH project is clearly oriented toward industry, even if most technology building blocks |
---|
| 73 | have been previously developed by academic laboratories. |
---|
| 74 | |
---|
| 75 | |
---|
| 76 | %Finally, the key points of the proposed design flow are : |
---|
| 77 | %\begin{itemize} |
---|
| 78 | %\item |
---|
| 79 | %\textbf{System level exploration}: The application coarse grain parallelism |
---|
| 80 | %is explicitely described as a Tasks and Communication Graph (TCG). |
---|
| 81 | %A template architecture is selected, and the performances are evaluated |
---|
| 82 | %on various variant of this architecture using the SoCLib virtual protyping |
---|
| 83 | %environment. This result in a specific hardware/software partitioning. |
---|
| 84 | %This system level exploration is fully controlled by the system designer, and is driven |
---|
| 85 | %by cost, throughput, latency and power consumption criteria. |
---|
| 86 | % |
---|
| 87 | %\item |
---|
| 88 | %\textbf{High Level Synthesis}: When dedicated hardware coprocessors have been |
---|
| 89 | %identified as mandatory, they will be generated by the high level synthesis (HLS) tools. |
---|
[134] | 90 | %The COACH framework will integrate various HLS tools, supporting the micro-architectural space |
---|
[97] | 91 | %design exploration. Here again, the exploration criteria are cost, throughput, latency |
---|
| 92 | %and power consumption. |
---|
| 93 | %At this stage, preliminary source-level transformations and optimisations by front-end |
---|
| 94 | %tools will be required to improve the efficiency of the back-end HLS tools. |
---|
| 95 | % |
---|
| 96 | %\item |
---|
| 97 | %\textbf{Early performance evaluation}: For each point in the design space, |
---|
| 98 | %figures of merit must be available such as throughput, latency, power |
---|
| 99 | %consumption, area, memory allocation and data locality. They are evaluated |
---|
| 100 | %by reliable estimators obtained by running the actual multi-task software |
---|
| 101 | %application on the virtual prototype. |
---|
| 102 | % |
---|
| 103 | %\item |
---|
| 104 | %\textbf{Independance from the Target FPGA}: The COACH description of the system |
---|
| 105 | %(both hardware and software) should be independent of the FPGA family. |
---|
| 106 | %Every point of the design space can be implemented on any FPGA component, |
---|
| 107 | %as long as it contains the hardware ressources required by the selected architectural template. |
---|
[99] | 108 | %Basically, COACH will support both \altera and \xilinx FPGA families. |
---|
[97] | 109 | %\end{itemize} |
---|
| 110 | % |
---|
| 111 | |
---|
| 112 | |
---|
| 113 | |
---|