Related Work¶
A number of research projects, such as Lime~cite{REL:Lime}, BCL~cite{King:2012:AGH:2150976.2151011}, HThreads~cite{DBLP:conf/fpl/PeckAASBA06}, and CatapaultC~cite{CatC:www} (to name just a few) bridge the software/hardware development gap by providing a single language for developing both the software and hardware components of the design. In addition, Altera and Xilinx have both implemented OpenCL~cite{Opencl} on FPGAs~cite{AlteraOpencl,XilinxOpencl} in an attempt to attract GPU programmers.
The computation model of software differs significantly from that of hardware, and so far none of the unified language approaches deliver the same performance as languages designed specifically for hardware or software. Connectal is intended to be used for the design of performance-critical systems. In this context we think that designers prefer a mix of languages specifically designed for their respective implementation contexts.
Infrastructures such as LEAP~cite{DBLP:conf/fpl/FlemingYAE14}, Rainbow~cite{DBLP:journals/ijrc/JozwikHETT13}, and OmpSs~cite{DBLP:conf/fpga/FilguerasGJAMLNV14} (to name just a few) use resource abstraction to enable FPGA development. We found that in their intended context, these tools were easy to use but that performance tuning in applications not foreseen by the infrastructure developers was problematic.
Some projects such as TMD-MPI~cite{DBLP:journals/trets/SaldanaPMNWCWSP10}, VFORCE/ \VSIPL++~cite{DBLP:journals/jpdc/MooreLK12}, and GASNet/GAScore~cite{DBLP:conf/fpga/WillenbergC13} target only the hardware software interface. These tools provide message passing capabilities, but rely on purely operational semantics to describe the HW/SW interface. Apart from the implementation details, Connectal distinguishes itself by using an IDL to enforce denotational interface semantics.
UIO~cite{UIO:Howto} is a user-space device driver framework for Linux. It is very similar to the Connectal’s portal device driver, but it does not provide a solution to multiple device nodes per hardware device. The portal driver provides this so that different interfaces of a design may be accessed independently, providing process boundary protection, thread safety, and the ability for user processes and the kernel both to access the hardware device.