1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
\section{Conclusion}
\label{sec:conclusion}
We have presented \vericert{}, the first mechanically verified HLS tool for translating software in C into hardware in Verilog.
%In this article, we present \vericert{}, the first fully mechanised proof of correctness for HLS in Coq, translating C into Verilog.
We built \vericert{} by extending \compcert{} with a new hardware-specific intermediate language and a Verilog back end, and we verified it with respect to a semantics for Verilog due to \citet{loow19_proof_trans_veril_devel_hol}.
%The behaviour of any C program compiled via \vericert{} is guaranteed to be translated correctly to Verilog.
We evaluated \vericert{} against the existing \legup{} HLS tool on the \polybench{} benchmark suite.
%Our Polybench hardware is guaranteed to preserve the C behaviour, whilst \legup{} cannot provide any such guarantee about its generated hardware.
Currently, our hardware is \slowdownOrig$\times$ slower and \areaIncr$\times$ larger compared to \legup{}, though it is only \slowdownDiv$\times$ slower if inefficient divisions are removed.
There are abundant opportunities for improving \vericert{}'s performance. For instance, as discussed in Section~\ref{sec:evaluation}, simply replacing the na\"ive single-cycle division and modulo operations with C implementations increases clock frequency by $8.2\times$.
%Going forward, we envision introducing HLS-specific optimisations that are intended to improve the hardware quality of \vericert{}, whilst maintaining correctness.
% However, to make the tool more usable there are many more optimisations that could be implemented to get the performance closer to \legup{}.
Beyond this, we plan to implement scheduling and loop pipelining, since this allows more operations to be packed into fewer clock cycles.
% JW: I chopped the following because we mentioned Six et al already.
%recent work by \citet{six+20} indicates how these scheduling algorithms can be implemented in \compcert.
%Another possibility is re-using registers, since \compcert{}'s 3AC does not include register allocation.
Other optimisations include resource sharing to reduce the circuit area, and using tailored hardware operators that exploit the hard IP blocks of the chip and can be pipelined.
% this could include multi-cycle operations and pipelining optimisations so that division and multiplication operators also become more efficient.
Finally, it's worth considering how trustworthy \vericert{} is compared to other HLS tools. The guarantee of full functional equivalence between input and output has been both proven and fuzz-tested; the semantics for the source and target languages are both well established; and Coq is a mature and thoroughly tested system. Nonetheless, \vericert{} cannot guarantee to provide an output for every valid input -- for instance, as remarked in Section~\ref{sec:proof:htl_verilog}, \vericert{} will error out if given a program with more than about four million instructions! -- but our evaluation indicates that it does not seem to error out too frequently. And of course, \vericert{} cannot guarantee that the final hardware produced will be correct, because the Verilog it generates must pass through a series of unverified tools along the way. That concern may be allayed in the future thanks to recent work by~\citet{10.1145/3437992.3439916} to produce a verified logic synthesis tool.
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "main"
%%% End:
|
