- Timestamp:
- Feb 17, 2010, 3:59:30 PM (15 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
anr/section-3.1.tex
r247 r252 55 55 they are bound to a particular device family and to IPs library. 56 56 The most commonly used are provided by \altera and \xilinx to promote their 57 FPGA devices. These tworepresentative tools used to synthesize SoC on FPGA57 FPGA devices. These representative tools used to synthesize SoC on FPGA 58 58 are introduced below. 59 59 \\ … … 67 67 cannot handle a complete SoC. Thus, it is not really a system synthesis tool. 68 68 \\ 69 In the opposite, SOPC Builder~\cite{spoc-builder} allows to describe a 70 system, to synthesis it, to programm it into a target FPGA and to upload a 71 software application. 72 % FIXME(C2H from \altera, marche vite mais ressource monstrueuse) 73 Nevertheless, SOPC Builder does not provide any facilities to synthesize 74 coprocessors. System Designer must provide the synthesizable description 75 with the feasible bus interface. Design Space Exploration is thus limited 69 In the opposite, SOPC Builder~\cite{spoc-builder} from \altera and \xilinx 70 Platform Studio XPS from \xilinx allows to describe a system, to synthesis it, 71 to program it into a target FPGA and to upload a software application. 72 Both SOPC Builder and XPS, allow designers to select and parameterize components from 73 an extensive drop-down list of IP cores (I/O core, DSP, processor, bus core, ...) 74 as well as incorporate their own IP. Nevertheless, all the previously introduced tools 75 do not provide any facilities to synthesize coprocessors and to simulate the platform 76 at a high level (SystemC). 77 System designer must provide the synthesizable description of its own IP-cores with 78 the feasible bus interface. Design Space Exploration is thus limited 76 79 and SystemC simulation is not possible neither at transactional nor at cycle 77 80 accurate level. 78 81 \\ 79 In addition, \xilinx System Generator and SOPC Builder are closed world82 In addition, \xilinx System Generator, XPS and SOPC Builder are closed world 80 83 since each one imposes their own IPs which are not interchangeable. 81 %By using SOPC Builder~\cite{spoc-builder} from \altera, designers can select and 82 %parameterize components from an extensive drop-down list of IP cores (I/O core, DSP, 83 %processor, bus core, ...) as well as incorporate their own IP. 84 %Designers can then generate a synthesized netlist, simulation test bench and custom 85 %software library that reflect the hardware configuration. 86 %Nevertheless, SOPC Builder does not provide any facilities to synthesize coprocessors and to 87 %simulate the platform at a high design level (systemC). 88 %In addition, SOPC Builder is proprietary and only works together with \altera's Quartus compilation 89 %tool to implement designs on \altera devices (Stratix, Arria, Cyclone). 90 %PICO~\cite{pico} and CATAPULT-C~\cite{catapult-c} allow to synthesize 91 %coprocessors from a C++ description. 92 %Nevertheless, they can only deal with data dominated applications and they do not handle 93 %the platform level. 94 %Similarly, the System Generator for DSP~\cite{system-generateur-for-dsp} is a plug-in to 95 %Simulink that enables designers to develop high-performance DSP systems for \xilinx FPGAs. 96 %Designers can design and simulate a system using MATLAB and Simulink. The tool will then 97 %automatically generate synthesizable Hardware Description Language (HDL) code mapped to 98 %\xilinx pre-optimized macro-cells. 99 %However, this tool targets only DSP based algorithms. 100 %\\ 101 %Consequently, a designer developping an embedded system needs to master four different 102 %design environments: 103 %\begin{enumerate} 104 % \item a virtual prototyping environment such as SoCLib for system level exploration, 105 % \item an architecture compiler (such as SOPC Builder from \altera, or System generator 106 % from \xilinx) to define the hardware architecture, 107 % \item one or several HLS tools (such as PICO~\cite{pico} or CATAPULT-C~\cite{catapult-c}) for 108 % coprocessor synthesis, 109 % \item and finally backend synthesis tools (such as Quartus or Synopsys) for the bit-stream generation. 110 %\end{enumerate} 111 %Furthermore, mixing these tools requires an important interfacing effort and this makes 112 %the design process very complex and achievable only by designers skilled in many domains. 84 Designers can then only generate a synthesized netlist, VHDL/Verilog simulation test 85 bench and custom software library that reflect the hardware configuration. 86 87 Consequently, a designer developing an embedded system needs to master four different 88 design environments: 89 \begin{enumerate} 90 \item a virtual prototyping environment (in SystemC) for system level exploration, 91 \item an architecture compiler to define the hardware architecture (Verilog/VHDL), 92 \item one or several third-party HLS tools for coprocessor synthesis (C to RTL), 93 \item and finally back-end synthesis tools for the bit-stream generation (RTL to bitstream). 94 \end{enumerate} 95 Furthermore, mixing these tools requires an important interfacing effort and this makes 96 the design process very complex and achievable only by designers skilled in many domains. 113 97 114 98 \subsubsection{High Level Synthesis} … … 122 106 maturity, their usage is restrained by \cite{IEEEDT} \cite{CATRENE} \cite{HLSBOOK}: 123 107 \begin{itemize} 124 \item TheHLS tools are not integrated into an architecture and system exploration tool.108 \item HLS tools are not integrated into an architecture and system exploration tool. 125 109 Thus, a designer who needs to accelerate a software part of the system, must adapt it manually 126 to the HLS input dialect and perform sengineering work to exploit the synthesis result110 to the HLS input dialect and perform engineering work to exploit the synthesis result 127 111 at the system level, 128 112 \item Current HLS tools can not target control AND data oriented applications, 129 \item HLS tools take into account only one or few constraints simultaneously while realistic130 designs are multi-constrained,131 Moreover, low power consumption constraint is mandatory for embedded systems.132 However, it is not yet well handled or not handled at all by the synthesistools already available,133 \item The parallelism is extracted from initial algorithmicspecification.113 \item HLS tools take into account mainly a unique constraint while realistic design 114 is multi-constrained. 115 Low power consumption constraint which is mandatory for embedded systems is not yet 116 well handled or not handled at all by the HLS tools already available, 117 \item The parallelism is extracted from initial specification. 134 118 To get more parallelism or to reduce the amount of required memory in the SoC, the user 135 119 must re-write the algorithmic specification while there is techniques such as polyedric … … 152 136 ASIP (Application-Specific Instruction-Set Processor) are programmable 153 137 processors in which both the instruction and the micro architecture have 154 been tailored to a given application domain (e.g. video processing),or to a138 been tailored to a given application domain or to a 155 139 specific application. This specialization usually offers a good compromise 156 140 between performance (w.r.t a pure software implementation on an embedded
Note: See TracChangeset
for help on using the changeset viewer.