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