summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2020-09-15 11:23:44 +0100
committerYann Herklotz <git@yannherklotz.com>2020-09-15 11:23:44 +0100
commit3f6cc0f009f5d13dfd80c7fb6008062a44a94c66 (patch)
tree4bd8c5a5260e6d89fb4203881b201b778acf5d1e
parent669bc9dbe8f73b56ec34d68eecec9b7758d0890d (diff)
downloadfccm21_esrhls-3f6cc0f009f5d13dfd80c7fb6008062a44a94c66.tar.gz
fccm21_esrhls-3f6cc0f009f5d13dfd80c7fb6008062a44a94c66.zip
Add more descriptions
-rw-r--r--eval.tex6
1 files changed, 3 insertions, 3 deletions
diff --git a/eval.tex b/eval.tex
index 976a1ce..23abc5c 100644
--- a/eval.tex
+++ b/eval.tex
@@ -40,7 +40,7 @@
Intel i++ & $\ge 1$\\
\bottomrule
\end{tabular}
- \caption{Unique bugs found in each tool. %\JW{is `all versions' correct here? and should we add version numbers like in the Venn?}\YH{Yes it is actually correct here, I don't mind adding the specific version either though}\JW{Ok let's leave it as-is.}
+ \caption{Unique bugs found in each tool. The $\ge$ indicates a lower bound on the number of unique bugs that were found, which correspond to unique minimal test cases. %\JW{is `all versions' correct here? and should we add version numbers like in the Venn?}\YH{Yes it is actually correct here, I don't mind adding the specific version either though}\JW{Ok let's leave it as-is.}
}
\label{tab:unique_bugs}
\end{table}
@@ -156,7 +156,7 @@ The buggy test-case has to do with initialisation and assignment to a three-dime
\subsubsection{LegUp miscompilation}
-The test-case in Figure~\ref{fig:eval:legup:wrong} produces an incorrect Verilog in LegUp 4.0, which means that the results of RTL simulation is different to the C execution.
+The test-case in Figure~\ref{fig:eval:legup:wrong} produces an incorrect Verilog in LegUp 4.0 and 7.5, which means that the results of RTL simulation is different to the C execution.
\begin{figure}
\begin{minted}{c}
@@ -175,7 +175,7 @@ int main() {
\caption{An output mismatch: LegUp HLS returns 0 but the correct result is 1.}\label{fig:eval:legup:wrong}
\end{figure}
-In the code above, \texttt{b} has value 1 when run in GCC, but has value 0 when run with LegUp 4.0. If the \texttt{volatile} keyword is removed from \texttt{a}, then the Verilog produces the correct result. As \texttt{a} and \texttt{d} are constants, the \code{if} statement should always produce go into the \texttt{true} branch, meaning \texttt{b} should never be set to 0. The \texttt{true} branch of the \code{if} statement only executes an expression which is not assigned to any variable, meaning the initial state of all variables should not change. However, LegUp HLS generates a design which enters the \texttt{else} branch instead and assigns \texttt{b} to be 0. The cause of this bug seems to be the use of \texttt{volatile} keyword, which interferes with the analysis that attempts to simplify the \code{if} statement.
+In the code above, \texttt{b} has value 1 when run in GCC, but has value 0 when run with LegUp. If the \texttt{volatile} keyword is removed from \texttt{a}, then the Verilog produces the correct result. As \texttt{a} and \texttt{d} are constants, the \code{if} statement should always produce go into the \texttt{true} branch, meaning \texttt{b} should never be set to 0. The \texttt{true} branch of the \code{if} statement only executes an expression which is not assigned to any variable, meaning the initial state of all variables should not change. However, LegUp HLS generates a design which enters the \texttt{else} branch instead and assigns \texttt{b} to be 0. The cause of this bug seems to be the use of \texttt{volatile} keyword, which interferes with the analysis that attempts to simplify the \code{if} statement.
\subsubsection{Vivado HLS miscompilation}