Add

1 files changed, 1 insertions, 1 deletions

diff --git a/conclusion.tex b/conclusion.tex
index 5029bae..23476da 100644
--- a/conclusion.tex
+++ b/conclusion.tex
@@ -9,7 +9,7 @@ We evaluated \vericert{} against the existing \legup{} HLS tool on the \polybenc
 %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 $5.6\times$. 
+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; recent work by \citet{six+20} indicates how these scheduling algorithms can be implemented in \compcert.