Changeset 66 for anr/section-3.1.tex

Timestamp:

Feb 2, 2010, 10:03:39 PM (14 years ago)

Author:

coach

Message:

IA: modif UBS

File:

• anr/section-3.1.tex (modified) (3 diffs)

anr/section-3.1.tex

@@ -11 +11 @@
 many-core, GPGPU (General Purpose computation on Graphics Unit Processing) and FPGA.
 The two first families are dominating the market by taking benefit 
-of the strength and influence of mass-market leaders (Intel, Nvidia)
+of the strength and influence of mass-market leaders (Intel, Nvidia).
 %such as Intel for many-core CPU and Nvidia for GPGPU.
 In this market, FPGA architectures are emerging and very promising.
@@ -73 +73 @@
 In addition, Xilinx System Generator and SOPC Builder are closed world
 since each one imposes their own IPs which are not interchangeable.
-We can conclude that the existing commercial or free tools does not
-coverthe whole system synthesis process in a full automatic way. Moreover,
+The existing commercial or free tools does not
+cover the whole system synthesis process in a full automatic way. Moreover,
 they are bound to a particular device family and to IPs library.
 
 \subsubsection{High Level Synthesis}
 High Level Synthesis translates a sequential algorithmic description and a
-constraints set (area, power, frequency, ...) to a micro-architecture at
+set of constraints (area, power, frequency, ...) to a micro-architecture at
 Register Transfer Level (RTL).
 Several academic and commercial tools are today available. Most common
@@ -223 +223 @@
 an active research subject.
 
-\subsubsection{Interfaces}
-\newcommand{\ip}{\sc ip}
-\newcommand{\dma}{\sc dma}
-\newcommand{\soc}{\sc SoC}
-\newcommand{\mwmr}{\sc mwmr}
-The hardware/software interface has been a difficult task since the advent
-of complex systems on chip. After the first Co-design
-environments~\cite{Coware,Polis,Ptolemy}, the Hardware Abstraction Layer
-has been defined so that software applications can be developed without low
-level hardware implementation details.  In~\cite{jerraya}, Yoo and Jerraya
-propose an {\sc api} with extension ability instead of a unique hardware
-abstraction layer.  System level communication frameworks have been
-introduced~\cite{JerrayaPetrot,mwmr}.
-\par
-A good abstraction of a hardware/software interface has been proposed
-in~\cite{Jantsch}: it is composed of a software driver, a {\dma} and and a
-bus interface circuit. Automatic wrapping between bus protocols has
-generated a lot of papers~\cite{Avnit,smith,Narayan, Alberto}. These works
-do not use a {\dma}. In COACH, the hardware/software interface is done at a
-higher level and uses burst communication in the bus interface circuit to
-improve the communication performances.
-\par
-There are two important projects related to efficient interface of
-data-flow {\ip}s : the work of Park and Diniz~\cite{ Park01} and the the
-Lip6 work on {\mwmr}~\cite{mwmr}.  Park and Diniz~\cite{ Park01} proposed
-of a generic interface that can be parameterized to connect different
-data-flow {\ip}s. This approach does not request the communications to be
-statically known and proposes a runtime resolution to solve conflicting
-access to the bus. To our knowledge this approach has not been implemented
-further since 2003.
-\par
-{\mwmr}~\cite{mwmr} stands for both a computation model (multi-write,
-multi-read {\sc fifo}) inherited from the Khan Process Networks and a bus
-interface circuit protocol.  As for the work of Park and Diniz, {\mwmr}
-does not make the assumption of a static communication flow.  This implies
-simple software driver to write, but introduces additional complexity due
-to the mutual exclusion locks necessary to protect the shared memory.
-\par
-we propose, in COACH, to use recent work on hardware/software
-interface~\cite{FR-vlsi}  that  uses a {\em clever} {\dma} responsible for
-managing data streams. A assumption is that the behavior of the {\ip}s can
-be statically described. A similar choice has been made in the Faust
-{\soc}~\cite{FAUST} which includes the {\em smart memory engine} component.
-Jantsch and O'Nils already noticed in ~\cite{Jantsch} the huge complexity
-of writing this hardware/software interface, in COACH,  automatic
-generation of the interface will be achieved, this is one goal of the CITI
-contribution to COACH.
-
+%\subsubsection{High Performance Computing}
+%Accelerating high-performance computing (HPC) applications with field-programmable
+%gate arrays (FPGAs) can potentially improve performance. 
+%However, using FPGAs presents significant challenges~\cite{hpc06a}.
+%First, the operating frequency of an FPGA is low compared to a high-end microprocessor.
+%Second, based on Amdahl law,  HPC/FPGA application performance is unusually sensitive 
+%to the implementation quality~\cite{hpc06b}.
+%Finally, High-performance computing programmers are a highly sophisticated but scarce 
+%resource. Such programmers are expected to readily use new technology but lack the time 
+%to learn a completely new skill such as logic design~\cite{hpc07a} . 
+%\\
+%HPC/FPGA hardware is only now emerging and in early commercial stages, 
+%but these techniques have not yet caught up. 
+%Thus, much effort is required to develop design tools that translate high level
+%language programs to FPGA configurations.
+