[25] | 1 | The emerging complex and integrated heterogeneous embedded system platforms require |
---|
[69] | 2 | adequate design methods to efficiently model, explore, analyze and design the ever complex software |
---|
| 3 | and hardware architectures. In order to rapidly meet the increasing performance requirements and a pressure |
---|
| 4 | to lower development cost and shorten time-to-market, future embedded systems suppliers |
---|
| 5 | will have to adopt new design methodologies and flows in order to keep pace with the increasing |
---|
[25] | 6 | complexity of design problems. Such methods, addressing these challenges starting from high levels of |
---|
[32] | 7 | abstraction, will have to perform large solution space explorations both for software and (possibly |
---|
[38] | 8 | reconfigurable) hardware, reducing the design effort and offering a high predictability of results |
---|
| 9 | with respect to cost and performance objectives. |
---|
[69] | 10 | \\ |
---|
[25] | 11 | Current design methodologies provide quite low-level abstraction capabilities. However in a few years |
---|
[69] | 12 | from now, tens of programmable processors will be embedded in an IC with more than 100M |
---|
[38] | 13 | transistors, therefore adding to the complexity of the problem of designing such systems. |
---|
| 14 | Taking into account that the complexity of the software part is increasing at an even |
---|
| 15 | faster rate, current solutions for design space exploration, mainly manually based, by no |
---|
| 16 | means do supply an adequate efficiency. |
---|
[25] | 17 | Consequently, there is an urgent need to leverage system level |
---|
[69] | 18 | exploration through the use of a high-level specification of the application and an early design |
---|
[32] | 19 | space exploration step. The first system oriented approaches are appearing, among which those |
---|
| 20 | based on C/C++ and SystemC are the most popular. Such approaches can take place before and/or after |
---|
| 21 | the co-design or architecture refinement steps and target the design space pruning in order to fully |
---|
[25] | 22 | exploit potential solutions that meet design and application constraints (power, latency, |
---|
| 23 | throughput) within the design and market timeframe. |
---|
[17] | 24 | \\ |
---|
[25] | 25 | Thus, new system-level design flows need to be developed, enabling the exploration of an application |
---|
[38] | 26 | independently of the implementation, almost at the beginning of the design process. |
---|
| 27 | A fundamental element of this evolution is the definition of abstraction layers that should allow the |
---|
| 28 | performance driven re-use of software and hardware components at the system level. |
---|
| 29 | In this context, COACH will combine modeling and estimation methods and compilers and |
---|
| 30 | design space exploration techniques. This approach will be a radical innovation in |
---|
| 31 | embedded system design methodology. |
---|
[25] | 32 | \\ |
---|
[38] | 33 | The reason is that the COACH framework is applied before high-level design tools in the embedded |
---|
| 34 | systems design flow. In that way, it will make possible a real and efficiently combined |
---|
| 35 | exploitation of high-level synthesis tools, parallelizing approaches and compilers, already |
---|
[25] | 36 | available on the market. These tools and approaches are not yet massively adopted, precisely |
---|
[38] | 37 | because this preliminary design step is missing. COACH will indeed permit (i) to predict and |
---|
[25] | 38 | control implementation optimizations, (ii) to target multiple implementation technologies |
---|
| 39 | (and thus the associated tools) from a unique specification and (iii) to efficiently integrate high |
---|
| 40 | and low-level design tools in a unique seamless design flow. |
---|
| 41 | \\ |
---|
| 42 | The performance estimation methods combined with the design space exploration techniques will |
---|
| 43 | finally allow the design process to start from system level specification and automatically explore the |
---|
| 44 | potential architectures in order to find out the optimal implementation in a shorter design time and at |
---|
| 45 | a lower global cost. |
---|
[17] | 46 | \par |
---|
[38] | 47 | To get an efficient embedded system, the system designer has to take into account |
---|
| 48 | application characteristics when it chooses one of the available technologies. |
---|
| 49 | This choice is not easy and in most cases the designer has to try different |
---|
[17] | 50 | technologies to retain the most adapted one. |
---|
| 51 | \\ |
---|
| 52 | The first objective of COACH is to provide an open-source framework to |
---|
[38] | 53 | design embedded system on FPGA devices. |
---|
| 54 | The COACH framework allows the designer to explore various software/hardware |
---|
[17] | 55 | partitions of the target application, to run timing and functional |
---|
| 56 | simulations and to generate automatically both the software and the |
---|
| 57 | synthesizable description of the hardware. |
---|
| 58 | The main topics of the project are: |
---|
| 59 | \begin{itemize} |
---|
| 60 | \item |
---|
[69] | 61 | \textbf{Design space exploration}: It consists in analysing the application running |
---|
[17] | 62 | on FPGA, defining the target technology (SoC, MPSoC, ASIP, ...) and |
---|
| 63 | hardware/software partitioning of tasks depending on technology choice. |
---|
| 64 | This exploration is driven basically by throughput, latency and power |
---|
| 65 | consumption criteria. |
---|
| 66 | \item |
---|
[46] | 67 | \textbf{Micro-architectural exploration}: When hardware components are required, the |
---|
[17] | 68 | HLS tools of the framework generate them automatically. At this stage the |
---|
[38] | 69 | framework provides various HLS tools that allow the micro-architectural space |
---|
[30] | 70 | design exploration. The exploration criteria also are throughput, latency |
---|
[17] | 71 | and power consumption. |
---|
[30] | 72 | At this stage, preliminary source-level transformations will be |
---|
| 73 | required to improve the efficiency of the target component. |
---|
| 74 | For instance, one may transform a loop nest to expose parallelism, |
---|
| 75 | or shrink an array to promote it to a register or reduce a memory footprint. |
---|
| 76 | |
---|
[17] | 77 | \item |
---|
[46] | 78 | \textbf{Performance measurement}: For each point in the design space, |
---|
[38] | 79 | figures of merit are available such as throughput, latency, power |
---|
[17] | 80 | consumption, area, memory allocation and data locality. They are evaluated |
---|
[38] | 81 | using virtual prototyping, estimation or analyzing methodologies. |
---|
[17] | 82 | \item |
---|
[46] | 83 | \textbf{Targeted hardware technology}: The COACH description of a system is |
---|
[38] | 84 | independent of the FPGA family. Every point of the design |
---|
[17] | 85 | space can be implemented on any FPGA having the required resources. |
---|
| 86 | Basically, COACH handles both Altera and Xilinx FPGA families. |
---|
| 87 | \end{itemize} |
---|
| 88 | As an extension of embedded system design, COACH deals also with High |
---|
| 89 | Performance Computing (HPC). |
---|
[38] | 90 | In HPC, the kind of targeted application is an existing one running on a PC. |
---|
| 91 | The COACH framework helps designer to accelerate it by migrating critical parts into a |
---|
| 92 | SoC implemented on an FPGA plugged to the PC bus. |
---|
[17] | 93 | \par |
---|
[38] | 94 | COACH is the result of the will of several laboratories to unify their knowhow |
---|
| 95 | and skills in the following domains: Operating system and hardware |
---|
[46] | 96 | communication (\tima, \upmc), SoC and MPSoC (\upmc and \tima), ASIP (\irisa) and |
---|
[38] | 97 | HLS (\upmc, \ubs) and compilation (\irisa, \lip). |
---|
[17] | 98 | The project objective is to integrate these various domains into a unique |
---|
| 99 | free framework (licence ...) masking as much as possible these domains and |
---|
| 100 | its different tools to the user. |
---|
| 101 | |
---|