Add more stuff

1 files changed, 11 insertions, 5 deletions

diff --git a/method-new.tex b/method-new.tex
index 8ff8281..ef8c62c 100644
--- a/method-new.tex
+++ b/method-new.tex
@@ -89,10 +89,14 @@ More importantly, we disable the generation of several language features to enab
 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 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...}
 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?} 
+
+To differentiate between if a feature should be disabled or reported as a bug, the tool in question is taken into account.  Unfortunately there is no standard subset of C that should be supported by HLS tools, and every tool chooses a slightly different subset.  It is therefore important to choose the right subset so that the most bugs are found in each tool, but we are not generating code that the tool does not support.  Therefore, to decide if a feature should be disable it should fail gracefully in one of the tools, stating that the feature is not supported or explaining what the issue is.  If the HLS tool fails in a different way though, such as generating a wrong design or crashing during synthesis, the feature is kept in the generated test cases.
+
+Use a volatile pointer for any pointer that is accessed multiple times within a single transaction (one execution of the C function). If you do not use a volatile pointer, everything except the first read and last write is optimized out to adhere to the C standard.
+
 We enforce that the main function of each generated program must not have any input arguments to allow for HLS synthesis. 
 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 bitwise AND and OR operations because when applied to constant operands, some versions of Vivado HLS errored out with `Wrong pragma usage.' 
@@ -179,11 +183,13 @@ We do not count time-outs as bugs, but we record them.
 
 %  And the number of timeouts placed has increased to 4. The first timeout sets when compiling the C++ program to CPU and returning an executable once finished. The second timeout is placed when running the executable to get the C++ result. The third timeout, which been given the most extended period, is at synthesizing the design and generating the co-simulation executable. Finally, running the co-simulation executable requires the fourth timeout. The test case can be dumped at any timeout period if the task is not finished within the limited time.
 
-\subsection{Reducing buggy programs}
-\label{sec:method:reduce}
+\subsection{Reducing buggy programs}\label{sec:method:reduce}
+
 Once we discover a program that crashes the HLS tool or whose C/RTL simulations do not match, we further scrutinise the program to identify the root cause(s) of the undesirable behaviour.
 As the programs generated by Csmith can be fairly large, we must systematically reduce these programs to identify the source of a bug.
 
+\YH{Edit this section some more}
+
 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.