Changeset 252


Ignore:
Timestamp:
Feb 17, 2010, 3:59:30 PM (14 years ago)
Author:
coach
Message:

UBS

File:
1 edited

Legend:

Unmodified
Added
Removed
  • anr/section-3.1.tex

    r247 r252  
    5555they are bound to a particular device family and to IPs library.
    5656The most commonly used are provided by \altera and \xilinx to promote their
    57 FPGA devices. These two representative tools used to synthesize SoC on FPGA
     57FPGA devices. These representative tools used to synthesize SoC on FPGA
    5858are introduced below.
    5959\\
     
    6767cannot handle a complete SoC. Thus, it is not really a system synthesis tool.
    6868\\
    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
     69In the opposite, SOPC Builder~\cite{spoc-builder} from \altera and \xilinx
     70Platform Studio XPS from \xilinx allows to describe a system, to synthesis it,
     71to program it into a target FPGA and to upload a software application.
     72Both SOPC Builder and XPS, allow designers to select and parameterize components from
     73an extensive drop-down list of IP cores (I/O core, DSP, processor,  bus core, ...)
     74as well as incorporate their own IP. Nevertheless, all the previously introduced tools
     75do not provide any facilities to synthesize coprocessors and to simulate the platform
     76at a high level (SystemC).
     77System designer must provide the synthesizable description of its own IP-cores with
     78the feasible bus interface. Design Space Exploration is thus limited
    7679and SystemC simulation is not possible neither at transactional nor at cycle
    7780accurate level.
    7881\\
    79 In addition, \xilinx System Generator and SOPC Builder are closed world
     82In addition, \xilinx System Generator, XPS and SOPC Builder are closed world
    8083since 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.
     84Designers can then only generate a synthesized netlist, VHDL/Verilog simulation test
     85bench and custom software library that reflect the hardware configuration.
     86
     87Consequently, a designer developing an embedded system needs to master four different
     88design 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}
     95Furthermore, mixing these tools requires an important interfacing effort and this makes
     96the design process very complex and achievable only by designers skilled in many domains.
    11397
    11498\subsubsection{High Level Synthesis}
     
    122106maturity, their usage is restrained by \cite{IEEEDT} \cite{CATRENE} \cite{HLSBOOK}:
    123107\begin{itemize}
    124 \item The HLS 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.
    125109Thus, a designer who needs to accelerate a software part of the system, must adapt it manually
    126 to the HLS input dialect and performs engineering work to exploit the synthesis result
     110to the HLS input dialect and perform engineering work to exploit the synthesis result
    127111at the system level,
    128112\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 realistic
    130 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 synthesis tools already available,
    133 \item The parallelism is extracted from initial algorithmic specification.
     113\item HLS tools take into account mainly a unique constraint while realistic design
     114is multi-constrained.
     115Low power consumption constraint which is mandatory for embedded systems is not yet
     116well handled or not handled at all by the HLS tools already available,
     117\item The parallelism is extracted from initial specification.
    134118To get more parallelism or to reduce the amount of required memory in the SoC, the user
    135119must re-write the algorithmic specification while there is techniques such as polyedric
     
    152136ASIP (Application-Specific Instruction-Set Processor) are programmable
    153137processors in which both the instruction and the micro architecture have
    154 been tailored to a given application domain (e.g. video processing), or to a
     138been tailored to a given application domain or to a
    155139specific application.  This specialization usually offers a good compromise
    156140between performance (w.r.t a pure software implementation on an embedded
Note: See TracChangeset for help on using the changeset viewer.