summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJohn Wickerson <j.wickerson@imperial.ac.uk>2020-11-18 21:49:59 +0000
committeroverleaf <overleaf@localhost>2020-11-18 22:05:57 +0000
commitf391370cd91c5848496ae47ab246afa0a0bbd6e2 (patch)
tree74e2a723d0c9fbbd683de54137c843e32b1c6dcf
parent7ed3d190813041a421e50bf88d3f6a26416a4a79 (diff)
downloadoopsla21_fvhls-f391370cd91c5848496ae47ab246afa0a0bbd6e2.tar.gz
oopsla21_fvhls-f391370cd91c5848496ae47ab246afa0a0bbd6e2.zip
Update on Overleaf.
-rw-r--r--algorithm.tex7
-rw-r--r--references.bib29
2 files changed, 34 insertions, 2 deletions
diff --git a/algorithm.tex b/algorithm.tex
index 0f2f5d5..88fd360 100644
--- a/algorithm.tex
+++ b/algorithm.tex
@@ -7,8 +7,11 @@ This section covers the main architecture of the HLS tool, and the way in which
First of all, the choice of C for the input language of \vericert{} is simply because it is what most major HLS tools use~\cite{canis11_legup, xilinx20_vivad_high_synth, intel_hls, bambu_hls}. This, in turn, may be because C is ``[t]he starting point for the vast majority of algorithms to be implemented in hardware''~\cite{5522874}.
%Since a lot of existing code for HLS is written in C, supporting C as an input language, rather than a custom domain-specific language, means that \vericert{} is more practical.
%An alternative was to support LLVM IR as an input language, however, to get a full work flow from a higher level language to hardware, a front end for that language to LLVM IR would also have to be verified. \JW{Maybe save LLVM for the `Choice of implementation language'?}
-\JW{We considered Bluespec~\cite{}, but decided that although it ``can be classed as a high-level language''~\cite{greaves_note}, it is too hardware-oriented to be considered proper HLS.}
-We also considered following the lead of \citet{page91_compil_occam} by using an Occam-like language, as it has built-in parallel constructs that map well to parallel hardware. However, this would not qualify as being high-level synthesis due to the manual parallelism that would have to be performed. \JW{I don't think the presence of parallelism stops it being proper HLS.} \JP{I think I agree with Yann here, but it could be worded better. At any rate not many people have experience writing what is essentially syntactic sugar over a process calculus.}
+\JW{We considered Bluespec~\cite{bluespec}, but decided that although it ``can be classed as a high-level language''~\cite{greaves_note}, it is too hardware-oriented to be used for traditional HLS.
+We also considered using a language with built-in parallel constructs that map well to parallel hardware, such as occam~\cite{page91_compil_occam} or Spatial~\cite{spatial}, but found these languages are too niche.}
+% However, this would not qualify as being HLS due to the manual parallelism that would have to be performed. \JW{I don't think the presence of parallelism stops it being proper HLS.}
+%\JP{I think I agree with Yann here, but it could be worded better. At any rate not many people have experience writing what is essentially syntactic sugar over a process calculus.}
+%\JW{I mean: there are plenty of software languages that involve parallel constructs. Anyway, perhaps we can just dismiss occam for being too obscure.}
\paragraph{Choice of target language}
diff --git a/references.bib b/references.bib
index 3c54005..6ea9e0b 100644
--- a/references.bib
+++ b/references.bib
@@ -49,6 +49,35 @@ year = {2020},
pages={857-858},
doi={10.1145/1837274.1837489}}
+@INPROCEEDINGS{bluespec,
+ author={Nikhil, Rishiyur S. },
+ booktitle={Proceedings. Second ACM and IEEE International Conference on Formal Methods and Models for Co-Design, 2004. MEMOCODE '04.},
+ title={Bluespec System Verilog: efficient, correct RTL from high level specifications},
+ year={2004},
+ volume={},
+ number={},
+ pages={69-70},
+ doi={10.1109/MEMCOD.2004.1459818}}
+
+@inproceedings{spatial,
+ author = {David Koeplinger and
+ Matthew Feldman and
+ Raghu Prabhakar and
+ Yaqi Zhang and
+ Stefan Hadjis and
+ Ruben Fiszel and
+ Tian Zhao and
+ Luigi Nardi and
+ Ardavan Pedram and
+ Christos Kozyrakis and
+ Kunle Olukotun},
+ title = {Spatial: a language and compiler for application accelerators},
+ booktitle = {{PLDI}},
+ pages = {296--311},
+ publisher = {{ACM}},
+ year = {2018}
+}
+
@article{greaves_note,
author = {David J. Greaves},
title = {Research Note: An Open Source Bluespec Compiler},