Update on Overleaf.

2 files changed, 32 insertions, 26 deletions

diff --git a/eval_rewrite.tex b/eval_rewrite.tex
index f63ee21..df7d42f 100644
--- a/eval_rewrite.tex
+++ b/eval_rewrite.tex
@@ -134,31 +134,38 @@ In addition to the explanation to bugs given in Section~\ref{sec:evaluation}, bu
 \begin{figure}
   \centering
   \begin{tikzpicture}
-    \fill[ribbon1,rounded corners=5pt] (-1.0,4.1) -- (0.0,4.1000000000000005) to [out=0,in=180] (2.0,4.1000000000000005) to [out=0,in=180] (4.0,4.1000000000000005) -- (6.0,4.1000000000000005) -- (7.55,3.325) -- (6.0,2.5500000000000003) -- (4.0,2.5500000000000003) to [out=180,in=0] (2.0,2.5500000000000003) to [out=180,in=0] (0.0,2.5500000000000003) -- (-1.0,2.55) -- cycle;
-    \fill[ribbon2,rounded corners=5pt] (-1.0,2.55) -- (0.0,2.5500000000000003) to [out=0,in=180] (2.0,1.8) to [out=0,in=180] (4.0,1.55) -- (6.0,1.55) -- (7.3,0.9) -- (6.0,0.25) -- (4.0,0.25) to [out=180,in=0] (2.0,0.5) to [out=180,in=0] (0.0,1.25) -- (-1.0,1.25) -- cycle;
-    \fill[ribbon3,rounded corners=0pt] (-1.0,1.25) -- (0.0,1.25) to [out=0,in=180] (2.0,2.5500000000000003) to [out=0,in=180] (4.0,0.25) -- (6.0,0.25) -- (6.05,0.225) -- (6.0,0.2) -- (4.0,0.2) to [out=180,in=0] (2.0,2.5) to [out=180,in=0] (0.0,1.2000000000000002) -- (-1.0,1.2) -- cycle;
-    \fill[ribbon4,rounded corners=1pt] (-1.0,0.5) -- (0.0,0.5) to [out=0,in=180] (2.0,2.5) to [out=0,in=180] (4.0,0.2) -- (6.0,0.2) -- (6.2,0.1) -- (6.0,0.0) -- (4.0,0.0) to [out=180,in=0] (2.0,2.3000000000000003) to [out=180,in=0] (0.0,0.30000000000000004) -- (-1.0,0.3) -- cycle;
-    \fill[ribbon5,rounded corners=1pt] (-1.0,1.2) -- (0.0,1.2000000000000002) to [out=0,in=180] (2.0,0.5) to [out=0,in=180] (4.0,2.5500000000000003) -- (6.0,2.5500000000000003) -- (6.2,2.45) -- (6.0,2.35) -- (4.0,2.35) to [out=180,in=0] (2.0,0.30000000000000004) to [out=180,in=0] (0.0,1.0) -- (-1.0,1.0) -- cycle;
-    \fill[ribbon6,rounded corners=1pt] (-1.0,0.3) -- (0.0,0.30000000000000004) to [out=0,in=180] (2.0,0.30000000000000004) to [out=0,in=180] (4.0,2.35) -- (6.0,2.35) -- (6.3,2.2) -- (6.0,2.0500000000000003) -- (4.0,2.0500000000000003) to [out=180,in=0] (2.0,0.0) to [out=180,in=0] (0.0,0.0) -- (-1.0,0.0) -- cycle;
-
-    \filldraw[fill=white] (-0.4,4.1) rectangle (0.0,1.0);
-    \filldraw[fill=white] (1.8,4.1) rectangle (2.2,2.3);
-    \filldraw[fill=white] (3.8,4.1) rectangle (4.2,2.05);
+    \draw[white, fill=ribbon1] (-1.0,4.1) -- (0.0,4.1000000000000005) to [out=0,in=180] (2.0,4.1000000000000005) to [out=0,in=180] (4.0,4.1000000000000005) -- (6.0,4.1000000000000005) -- %(7.55,3.325) -- 
+    (6.0,2.5500000000000003) -- (4.0,2.5500000000000003) to [out=180,in=0] (2.0,2.5500000000000003) to [out=180,in=0] (0.0,2.5500000000000003) -- (-1.0,2.55) -- cycle;
+    \draw[white, fill=ribbon2] (-1.0,2.55) -- (0.0,2.5500000000000003) to [out=0,in=180] (2.0,1.8) to [out=0,in=180] (4.0,1.55) -- (6.0,1.55) -- %(7.3,0.9) -- 
+    (6.0,0.25) -- (4.0,0.25) to [out=180,in=0] (2.0,0.5) to [out=180,in=0] (0.0,1.25) -- (-1.0,1.25) -- cycle;
+    \draw[white, fill=ribbon3] (-1.0,1.25) -- (0.0,1.25) to [out=0,in=180] (2.0,2.5500000000000003) to [out=0,in=180] (4.0,0.25) -- (6.0,0.25) -- %(6.05,0.225) -- 
+    (6.0,0.2) -- (4.0,0.2) to [out=180,in=0] (2.0,2.5) to [out=180,in=0] (0.0,1.2000000000000002) -- (-1.0,1.2) -- cycle;
+    \draw[white, fill=ribbon4] (-1.0,0.5) -- (0.0,0.5) to [out=0,in=180] (2.0,2.5) to [out=0,in=180] (4.0,0.2) -- (6.0,0.2) -- %(6.2,0.1) --
+    (6.0,0.0) -- (4.0,0.0) to [out=180,in=0] (2.0,2.3000000000000003) to [out=180,in=0] (0.0,0.30000000000000004) -- (-1.0,0.3) -- cycle;
+    \draw[white, fill=ribbon5] (-1.0,1.2) -- (0.0,1.2000000000000002) to [out=0,in=180] (2.0,0.5) to [out=0,in=180] (4.0,2.5500000000000003) -- (6.0,2.5500000000000003) -- %(6.2,2.45) --
+    (6.0,2.35) -- (4.0,2.35) to [out=180,in=0] (2.0,0.30000000000000004) to [out=180,in=0] (0.0,1.0) -- (-1.0,1.0) -- cycle;
+    \draw[white, fill=ribbon6] (-1.0,0.3) -- (0.0,0.30000000000000004) to [out=0,in=180] (2.0,0.30000000000000004) to [out=0,in=180] (4.0,2.35) -- (6.0,2.35) -- %(6.3,2.2) -- 
+    (6.0,2.0500000000000003) -- (4.0,2.0500000000000003) to [out=180,in=0] (2.0,0.0) to [out=180,in=0] (0.0,0.0) -- (-1.0,0.0) -- cycle;
+
+    \draw[white, fill=black] (-0.4,4.1) rectangle (0.0,1.0);
+    \draw[white, fill=black] (1.8,4.1) rectangle (2.2,2.3);
+    \draw[white, fill=black] (3.8,4.1) rectangle (4.2,2.05);
 
     \node at (-0.2,4.5) {2018.3};
     \node at (2,4.5) {2019.1};
     \node at (4,4.5) {2019.2};
-    \node at (2,5) {Vivado HLS};
+    %\node at (2,5) {Vivado HLS};
 
     \node at (5.5,3.325) {31};
     \node at (5.5,0.9) {26};
     \node at (5.5,2.2) {6};
 
-    \node at (-0.2,1.2) {62};
-    \node at (2,2.5) {36};
-    \node at (4,2.25) {41};
+    \node[white] at (-0.2,1.2) {62};
+    \node[white] at (2,2.5) {36};
+    \node[white] at (4,2.25) {41};
   \end{tikzpicture}
-  \caption{Sankey diagram showing the different bugs in Vivado HLS out of 3645 test cases.  Each ribbon shows one group of bugs which each failed in the same versions.}\label{fig:sankey_diagram}
+  \caption{A Sankey diagram that tracks 3645 test cases through three different versions of Vivado HLS. The ribbons collect the test cases that pass and fail together. The 3573 test cases that pass in all three versions are not depicted. }
+  \label{fig:sankey_diagram}
 \end{figure}
 
 %%% Local Variables:
diff --git a/method-new.tex b/method-new.tex
index 0632ade..fb0a250 100644
--- a/method-new.tex
+++ b/method-new.tex
@@ -80,28 +80,27 @@ This is vital for our work since we want to generate programs that are HLS-frien
 Table~\ref{tab:properties} lists the main changes that we put in place to ensure that HLS tools are able to synthesise all of our generated programs. 
 Our overarching aim is to make the programs tricky for the tools to handle correctly (in order to maximise our chances of exposing bugs), while keeping the synthesis and simulation times low (in order to maximise the rate at which tests can be run).
 To this end, we increase the probability of generating \code{if} statements in order to increase the number of control paths, but we reduce the probability of generating \code{for} loops and array operations since they generally increase run times but not hardware complexity.
-Additionally, we reduce the probability of complex control paths by limiting the generation of \code{break}, \code{goto}, \code{continue} and \code{return} statements, since they are seldom used in the HLS context. 
+Relatedly, we reduce the probability of generating \code{break}, \code{goto}, \code{continue} and \code{return} statements, because with fewer \code{for} loops being generated, these statements tend to lead to uninteresting programs that simply exit prematurely.
 
 %\paragraph{Important restrictions}
-More importantly, we disable the generation of a list of features to enable HLS testing. 
+More importantly, we disable the generation of several language features to enable HLS testing. 
 % \NR{Few sentences on different features whose probabilities were changed significantly.}
 % Table~\ref{tab:properties} lists the important restrictions that we put in place to ensure that HLS tools are able to synthesise programs generated by Csmith. 
-Firstly, we ensure all math expressions are safe and unsigned, to ensure no undefined behaviour. 
-We also disable assignments to be embedded within expressions, since HLS generally does not support them.
-We eliminate any floating-point numbers as part of HLS testing, since they typically involve external libraries or use of hard IPs on FPGA that is hard to then reduce to a minimal bug.
-We also disable the generation of pointers for HLS testing, since pointer support in HLS tools are either absent or not mature~\cite{xilinx20_vivad_high_synth}. 
+First, we ensure that all mathematical expressions are safe and unsigned, to ensure no undefined behaviour. 
+We also disallow assignments being embedded within expressions, since HLS generally does not support them.
+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}. 
 We also disable void functions, since we are not supporting pointers.
-We disable generation of unions as these weren't well supported by some of the tools such as LegUp 4.0.
+We disable the generation of unions as these were not well supported by some of the tools such as LegUp 4.0.
 \JW{Obvious reader question at this point: if a feature is badly-supported by some HLS tool(s), how do we decide between disabling it in Csmith vs. keeping it in and filing lots of bug reports? For instance, we say that we disable pointers because lots of HLS tools don't cope well with them, but we keep in `volatile' which also leads to problems. Why the different treatments?} 
 We enforce that the main function of each generated program must not have any input arguments to allow for HLS synthesis. 
-%\JW{`effective' is rather vague. Can we put in a better justification here?}
 We disable structure packing within Csmith since the ``\code{\#pragma pack(1)}'' directive involved causes conflicts in HLS tools because it is interpreted as an unsupported pragma. 
-We also disable generation of bitwise AND and OR operations because when applied to constant operands, some versions of Vivado HLS errored out with `Wrong pragma usage.' 
+We also disable bitwise AND and OR operations because when applied to constant operands, some versions of Vivado HLS errored out with `Wrong pragma usage.' 
 %\NR{Did we report this problem to the developers? If so, can we claim that here?}\YH{We haven't I think, we only reported one bug.}
 
 %\paragraph{Parameter settings}
-Finally, we control several integer parameters that influence program generation. 
-We limit the maximum number of functions (five) and array dimensions (three) in our random C programs. We reduced these numbers to reduce the design complexity and size. 
+Finally, we tweak several integer parameters that influence program generation. 
+We limit the maximum number of functions (five) and array dimensions (three) in our random C programs, in order to reduce the design complexity and size. 
 %\JW{Is this bigger or smaller than the default? Either way: why did we make this change?}
 We also limit the depth of statements and expressions, to reduce the synthesis and simulation times. 
 % \JW{Why? Presumably this is to do with keeping synthesis/simulation times as low as possible?}