Changeset 97 for anr/section-2.tex
- Timestamp:
- Feb 5, 2010, 10:16:22 PM (15 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
anr/section-2.tex
r69 r97 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. 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 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) hardware, reducing the design effort and offering a high predictability of results 9 with respect to cost and performance objectives. 10 \\ 11 Current design methodologies provide quite low-level abstraction capabilities. However in a few years 12 from now, tens of programmable processors will be embedded in an IC with more than 100M 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. 17 Consequently, there is an urgent need to leverage system level 18 exploration through the use of a high-level specification of the application and an early design 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 22 exploit potential solutions that meet design and application constraints (power, latency, 23 throughput) within the design and market timeframe. 24 \\ 25 Thus, new system-level design flows need to be developed, enabling the exploration of an application 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. 32 \\ 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 36 available on the market. These tools and approaches are not yet massively adopted, precisely 37 because this preliminary design step is missing. COACH will indeed permit (i) to predict and 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. 1 The first objective of COACH is to provide SMEs (Small and Medium Enterprises) an open-source framework to 2 design embedded system on FPGA devices. 3 4 Due to the exploding fabrication costs, the ASIC technology (Application Specific Integrated Circuit) 5 is not an option for most SMEs. Fortunately, the new FPGA (Field Programmable Gate Array) components, 6 such as the Virtex5 family from Xilinx, or the Stratix4 family from Altera can implement a complete 7 multi-processor architecture on a single chip. 8 9 %But the design of a SoC (System on Chip) or MPSoC (Multi-Processor System on Chip) is a complex 10 %task, requiring adequate design methods to efficiently model, explore, and analyze the 11 %interactions between the software application and the hardware architectures. Moreover, most SMEs do not have 12 %in-home expertise in the field of hardware design or VHDL/Verilog modeling. 13 %In order to meet the increasing performance requirements, to decrease the development cost, and to 14 %shorten the time-to-market, they need new design methodologies. 15 16 %Current design methodologies provide quite low-level abstraction capabilities, and 17 %there is an urgent need to leverage system level exploration through the use of a high-level 18 %specification of the application and design space exploration tools. 19 20 %The first system oriented approaches are appearing, among which those 21 %based on C/C++ and SystemC are the most popular, but few of them are specifically targetting FPGAs. 22 23 The COACH project will leverage on the expertise gained in the field of virtual prototyping 24 with the SoCLib platform, to propose a new design flow based on a small number of architectural templates. 25 An architectural template is a generic, parametrized architecture, relying on a predefined library 26 of IP cores. 27 Besides using a specific collection of general purpose IP cores (such as processors cores, 28 embedded memory controllers, system bus controllers, I/O and peripheral controllers), each architectural 29 template can be enriched by dedicated hardware coprocessors, obtained by high level synthesis (HLS) tools. 30 During this project, the COACH partners will develop three different architectural templates: 31 32 \begin{enumerate} 33 \item An \altera architectural template based on the \altera IP core library and the AVALON system bus. 34 \item A \xilinx architectural template based on the Xlinx IP core library and the OPB system bus. 35 \item A Neutral architectural template based on the SoCLib IP core library and the VCI/OCP communication infrastructure. 36 \end{enumerate} 37 38 The proposed design flow starts from a high level description of the application, specified as a set of 39 parallel tasks written in C, without any assumption on the hardware or software implementation 40 of these tasks. It let the system 41 designer in charge of expessing the coarse grain parallelism of the application, gives the designer 42 the possibility to explore various mapping of the application on the selected template architecture, 43 and offers a high predictability of results with respect to cost and performance objectives. 44 45 When this interactive, system level, design space exploration is completed (converging to 46 a specific mapping on a specific version of the selected architectural template), the rest of the flow 47 is fully automated: The synthesisable VHDL models for the various hardware components, as well as the binary 48 code for the software running on the embedded processors, and the bit-stream to program the the target FPGA 49 will be automatically generated by the COACH tools. 50 46 51 \par 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 50 technologies to retain the most adapted one. 51 \\ 52 The first objective of COACH is to provide an open-source framework to 53 design embedded system on FPGA devices. 54 The COACH framework allows the designer to explore various software/hardware 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 61 \textbf{Design space exploration}: It consists in analysing the application running 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 67 \textbf{Micro-architectural exploration}: When hardware components are required, the 68 HLS tools of the framework generate them automatically. At this stage the 69 framework provides various HLS tools that allow the micro-architectural space 70 design exploration. The exploration criteria also are throughput, latency 71 and power consumption. 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. 52 The strength of the COACH approach is the strong integration of the high-level synthesis tools 53 in a plat-form based design flow supporting virtual prototyping and design space exploration. 54 Most building blocks already exist (resulting from previous projects): the GAUT 55 or UGH synthesis tools, the MutekH or DNA embedded operating systems, the ASIP technology, 56 the DSX exploration tool, the MWMR hardware/software communication middleware, the BEE parallelisation tool, 57 as well as the SoCLib library of systemC simulation models. They must now be integrated in 58 a consistent design flow. 59 %The five academic laboratories worked very closely during more than one year (one monthly meeting 60 %in Paris from january 2009 to february 2010, to analyse the issues of interfacing and integrating 61 %those various technologies, and to define the detailed architecture of the proposed design flow. 62 \par 76 63 77 \item 78 \textbf{Performance measurement}: For each point in the design space, 79 figures of merit are available such as throughput, latency, power 80 consumption, area, memory allocation and data locality. They are evaluated 81 using virtual prototyping, estimation or analyzing methodologies. 82 \item 83 \textbf{Targeted hardware technology}: The COACH description of a system is 84 independent of the FPGA family. Every point of the design 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). 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. 93 \par 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 96 communication (\tima, \upmc), SoC and MPSoC (\upmc and \tima), ASIP (\irisa) and 97 HLS (\upmc, \ubs) and compilation (\irisa, \lip). 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. 64 In summary, the COACH project is clearly oriented toward industry, even if most technology building blocks 65 have been previously developed by academic laboratories. 101 66 67 68 %Finally, the key points of the proposed design flow are : 69 %\begin{itemize} 70 %\item 71 %\textbf{System level exploration}: The application coarse grain parallelism 72 %is explicitely described as a Tasks and Communication Graph (TCG). 73 %A template architecture is selected, and the performances are evaluated 74 %on various variant of this architecture using the SoCLib virtual protyping 75 %environment. This result in a specific hardware/software partitioning. 76 %This system level exploration is fully controlled by the system designer, and is driven 77 %by cost, throughput, latency and power consumption criteria. 78 % 79 %\item 80 %\textbf{High Level Synthesis}: When dedicated hardware coprocessors have been 81 %identified as mandatory, they will be generated by the high level synthesis (HLS) tools. 82 %The Coach framework will integrate various HLS tools, supporting the micro-architectural space 83 %design exploration. Here again, the exploration criteria are cost, throughput, latency 84 %and power consumption. 85 %At this stage, preliminary source-level transformations and optimisations by front-end 86 %tools will be required to improve the efficiency of the back-end HLS tools. 87 % 88 %\item 89 %\textbf{Early performance evaluation}: For each point in the design space, 90 %figures of merit must be available such as throughput, latency, power 91 %consumption, area, memory allocation and data locality. They are evaluated 92 %by reliable estimators obtained by running the actual multi-task software 93 %application on the virtual prototype. 94 % 95 %\item 96 %\textbf{Independance from the Target FPGA}: The COACH description of the system 97 %(both hardware and software) should be independent of the FPGA family. 98 %Every point of the design space can be implemented on any FPGA component, 99 %as long as it contains the hardware ressources required by the selected architectural template. 100 %Basically, COACH will support both Altera and Xilinx FPGA families. 101 %\end{itemize} 102 % 103 104 105
Note: See TracChangeset
for help on using the changeset viewer.