diff options
author | John Wickerson <j.wickerson@imperial.ac.uk> | 2021-04-16 09:25:45 +0000 |
---|---|---|
committer | overleaf <overleaf@localhost> | 2021-04-16 09:26:20 +0000 |
commit | 2356ba391f76e0af75a6bb2570826b3ea00413de (patch) | |
tree | a512d91d3fc69402680681e5c5a4069374695b40 /introduction.tex | |
parent | 1a63ce7aaf1f68437c67ba817e1ad8cdbf76d0ea (diff) | |
download | oopsla21_fvhls-2356ba391f76e0af75a6bb2570826b3ea00413de.tar.gz oopsla21_fvhls-2356ba391f76e0af75a6bb2570826b3ea00413de.zip |
Update on Overleaf.
Diffstat (limited to 'introduction.tex')
-rw-r--r-- | introduction.tex | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/introduction.tex b/introduction.tex index 30ad118..b532112 100644 --- a/introduction.tex +++ b/introduction.tex @@ -34,14 +34,14 @@ For example, the translation validation for Catapult C~\cite{mentor20_catap_high Our position is that none of the above workarounds are necessary if the HLS tool can simply be trusted to work correctly. \paragraph{Our solution} -We have designed a new HLS tool in the Coq theorem prover and proved that any output it produces always has the same behaviour as its input. Our tool, called \vericert{},\ifANONYMOUS\footnote{Tool name has been changed for blind review.}\fi{} is automatically extracted to an OCaml program from Coq, which ensures that the object of the proof is the same as the implementation of the tool. \vericert{} is built by extending the \compcert{} verified C compiler~\cite{leroy09_formal_verif_realis_compil} with a new hardware-specific intermediate language and a Verilog back end. It supports all C constructs except for case statements, function pointers, recursive function calls, integers larger than 32 bits, floats, and global variables. +We have designed a new HLS tool in the Coq theorem prover and proved that any output it produces always has the same behaviour as its input. Our tool, called \vericert{},\ifANONYMOUS\footnote{Tool name has been changed for blind review.}\fi{} is automatically extracted to an OCaml program from Coq, which ensures that the object of the proof is the same as the implementation of the tool. \vericert{} is built by extending the \compcert{} verified C compiler~\cite{leroy09_formal_verif_realis_compil} with a new hardware-specific intermediate language and a Verilog back end. It supports most C constructs, including integer operations, function calls, local arrays, structs, unions, and general control-flow statements, but currently excludes support for case statements, function pointers, recursive function calls, integers larger than 32 bits, floats, and global variables. \paragraph{Contributions and Outline} The contributions of this paper are as follows: \begin{itemize} - \item We present \vericert{}, the first mechanically verified HLS tool that compiles C to Verilog. In Section~\ref{sec:design}, we describe the design of \vericert{}. - \item We state the correctness theorem of \vericert{} with respect to an existing semantics for Verilog due to \citet{loow19_proof_trans_veril_devel_hol}. In Section~\ref{sec:verilog}, we describe how we lightly extended this semantics to make it suitable as an HLS target. + \item We present \vericert{}, the first mechanically verified HLS tool that compiles C to Verilog. In Section~\ref{sec:design}, we describe the design of \vericert{}, \JW{including a few optimisations related to memory accesses and division.} + \item We state the correctness theorem of \vericert{} with respect to an existing semantics for Verilog due to \citet{loow19_proof_trans_veril_devel_hol}. In Section~\ref{sec:verilog}, we describe how we lightly \JW{Maybe remove `lightly' now -- the changes feel a bit more than just `light' nowadays!} extended this semantics to make it suitable as an HLS target. \item In Section~\ref{sec:proof}, we describe how we proved the correctness theorem. The proof follows standard \compcert{} techniques -- forward simulations, intermediate specifications, and determinism results -- but we encountered several challenges peculiar to our hardware-oriented setting. These include handling discrepancies between byte- and word-addressable memories, different handling of unsigned comparisons between C and Verilog, correctly mapping CompCert's memory model onto a finite Verilog array and finally correctly rearranging memory reads and writes so that these behave properly as a RAM in hardware. \item In Section~\ref{sec:evaluation}, we evaluate \vericert{} on the \polybench{} benchmark suite~\cite{polybench}, and compare the performance of our generated hardware against an existing, unverified HLS tool called \legup{}~\cite{canis11_legup}. We show that \vericert{} generates hardware that is \slowdownOrig$\times$ slower (\slowdownDiv$\times$ slower in the absence of division) and \areaIncr$\times$ larger than that generated by \legup{}. We intend to bridge this performance gap in the future by introducing (and verifying) HLS optimisations of our own, such as scheduling and memory analysis. \end{itemize} @@ -50,7 +50,7 @@ The contributions of this paper are as follows: \begin{center} \ifANONYMOUS -\url{https://github.com/anonymised-for-blind-review} +[GitHub link removed for blind review] \else \url{https://github.com/ymherklotz/vericert} \fi |