Update on Overleaf.

1 files changed, 2 insertions, 4 deletions

diff --git a/method.tex b/method.tex
index 052f8b3..6651d33 100644
--- a/method.tex
+++ b/method.tex
@@ -58,7 +58,6 @@ This is vital for our work since we want to generate programs that are HLS-frien
       \code{statement\_break/goto/continue\_prob} & Reduced \\
       \code{float\_as\_ltype\_prob} &  Disabled \\
       \code{pointer\_as\_ltype\_prob} & Disabled \\
-      \code{void\_prob} & Disabled \\
       \code{union\_as\_ltype\_prob} &  Disabled \\
       \code{more\_struct\_union\_type\_prob} & Disabled \\
       \code{safe\_ops\_signed\_prob} & Disabled \\
@@ -95,7 +94,6 @@ We also disallow assignments being embedded within expressions, since HLS genera
 We eliminate any floating-point numbers since they typically involve external libraries or use of hard IPs on FPGAs, which in turn make it hard to reduce bugs to their minimal form.
 We also disable the generation of pointers for HLS testing, since pointer support in HLS tools is either absent or immature~\cite{xilinx20_vivad_high_synth}.
 %\YH{I've looked at the documentation and even pointer to pointer is supported, but maybe not pointer to pointer to pointer.  I think there was some other pointer assignment that didn't quite work, but I don't remember now.  Immature might be a good description though.}
-We also disable void functions, since we are not supporting pointers.
 %\YH{Figure \ref{fig:eval:vivado:mismatch} actually has void functions...} \JW{Hm, true. Perhaps these were introduced during reduction.}
 We disable the generation of unions as these were not supported by some of the tools such as LegUp 4.0.
 
@@ -173,7 +171,7 @@ Having generated HLS-friendly programs and automatically augmented them with dir
 %Figure~\ref{fig:method:toolflow} shows the three stages of testing, depicted as the testing environment in the dashed area.
 For each HLS tool in turn, we compile the C program to RTL and then simulate the RTL. 
 Independently, we also compile the C program using GCC and execute it. 
-To ensure that our testing is scalable for a large number of large, random programs, we also enforce several time-outs: we set a 5-minute time-out for C execution and a 2-hour time-out for RTL simulation.
+To ensure that our testing is scalable for a large number of large, random programs, we also enforce several time-outs: we set a 5-minute time-out for C execution and a 2-hour time-out for C-to-RTL synthesis and RTL simulation.
 We do not count time-outs as bugs, but we record them.
 
 %% JW: This paragraph is not really needed because we repeat the sentiment in the next subsection anyway.
@@ -199,7 +197,7 @@ As the programs generated by Csmith can be fairly large, we must systematically
 Reduction is performed by iteratively removing some part of the original program and then providing the reduced program to the HLS tool for re-synthesis and co-simulation. 
 The goal is to find the smallest program that still triggers the bug. 
 We apply two consecutive methods of reduction in this work. 
-The first step is to reduce the labels and pragmas that were added afterwards to make sure that these do not affect the behaviour of the program.  These are reduced iteratively until there are no more declarations left or the bug does not get triggered anymore.
+The first step is to reduce the labels and pragmas that were added afterwards to make sure that these do not affect the behaviour of the program.  These are reduced until there are no more declarations left or the bug does not get triggered anymore.
 % \NR{We can add one or two more sentences summarising how we reduce the programs. Zewei is probably the best person to add these sentences.}\YH{Added some more lines, we can ask Zewei if she is OK with that.}
 %Although, our custom reduction gives us the freedom and control of how to reduce buggy programs, it is arduous and requires a lot of manual effort.
 We then use the \creduce{} tool~\cite{creduce} to automatically reduce the remaining C program.