source: anr/section-2.tex @ 81

Last change on this file since 81 was 69, checked in by coach, 15 years ago

IA: modif UBS

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