summaryrefslogtreecommitdiffstats
path: root/related.tex
diff options
context:
space:
mode:
authorJohn Wickerson <j.wickerson@imperial.ac.uk>2021-08-11 13:38:31 +0000
committernode <node@git-bridge-prod-0>2021-08-11 13:39:10 +0000
commitaba1f5d550676af635889917ad79e0f5444f1b8b (patch)
tree74ca8d6d061d20a4f23239181ca9f53abc933e47 /related.tex
parente2e7ba544d650440ab2371c9a103ff2c8c8f9d1e (diff)
downloadoopsla21_fvhls-aba1f5d550676af635889917ad79e0f5444f1b8b.tar.gz
oopsla21_fvhls-aba1f5d550676af635889917ad79e0f5444f1b8b.zip
Update on Overleaf.
Diffstat (limited to 'related.tex')
-rw-r--r--related.tex2
1 files changed, 1 insertions, 1 deletions
diff --git a/related.tex b/related.tex
index 80b54e5..44dad6e 100644
--- a/related.tex
+++ b/related.tex
@@ -44,7 +44,7 @@
A summary of the related works can be found in Figure~\ref{fig:related_euler}, which is represented as an Euler diagram. The categories chosen for the Euler diagram are: whether the tool is usable \JWcouldcut{and available}, whether it takes a high-level software language as input, whether it has a correctness proof, and finally whether that proof is mechanised. The goal of \vericert{} is to cover all of these categories.
-Most practical HLS tools~\citep{canis11_legup,xilinx20_vivad_high_synth,intel20_sdk_openc_applic,nigam20_predic_accel_desig_time_sensit_affin_types} fit into the category of usable tools that take high-level inputs. On the other end of the spectrum, there are tools such as BEDROC~\citep{chapman92_verif_bedroc} for which there is no practical tool, and even though it is described as high-level synthesis, it more closely resembles today's hardware synthesis tools.
+Most practical HLS tools~\citep{canis11_legup,xilinx20_vivad_high_synth,intel20_sdk_openc_applic,nigam20_predic_accel_desig_time_sensit_affin_types} fit into the category of usable tools that take high-level inputs. On the other end of the spectrum, there are tools such as BEDROC~\citep{chapman92_verif_bedroc} for which there is no practical tool, and even though it is described as high-level synthesis, it more closely resembles today's logic synthesis tools.
Ongoing work in translation validation~\citep{pnueli98_trans} seeks to prove equivalence between the hardware generated by an HLS tool and the original behavioural description in C. An example of a tool that implements this is Mentor's Catapult~\citep{mentor20_catap_high_level_synth}, which tries to match the states in the 3AC description to states in the original C code after an unverified translation. Using translation validation is quite effective for verifying complex optimisations such as scheduling~\citep{kim04_autom_fsmd,karfa06_formal_verif_method_sched_high_synth,chouksey20_verif_sched_condit_behav_high_level_synth} or code motion~\citep{banerjee14_verif_code_motion_techn_using_value_propag,chouksey19_trans_valid_code_motion_trans_invol_loops}, but the validation has to be run every time the HLS is performed. In addition to that, the proofs are often not mechanised or directly related to the actual implementation, meaning the verifying algorithm might be wrong and hence could give false positives or false negatives.