summaryrefslogtreecommitdiffstats
path: root/related.tex
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2020-11-02 14:57:00 +0000
committerYann Herklotz <git@yannherklotz.com>2020-11-02 14:57:00 +0000
commit30b6a0f2a4709520d5aecec9959a2ea4f28b6529 (patch)
tree17cf6304c616e1fe907794416700110e4fab79ff /related.tex
parente40fa69ac8bf0a3b38edc63bdf33e4e879c42b9b (diff)
downloadoopsla21_fvhls-30b6a0f2a4709520d5aecec9959a2ea4f28b6529.tar.gz
oopsla21_fvhls-30b6a0f2a4709520d5aecec9959a2ea4f28b6529.zip
Add more content
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 f38a7c9..a2da530 100644
--- a/related.tex
+++ b/related.tex
@@ -1,6 +1,6 @@
\section{Related Work}
-Work is being done to prove the equivalence between the generated hardware and the original behavioural description in C. An example of a tool that implements this is Mentor's Catapult~\cite{mentor20_catap_high_level_synth}, which tries to match the states in the register transfer level (RTL) description to states in the original C code after an unverified translation. This technique is called translation validation~\cite{pnueli98_trans}, whereby the translation that the HLS tool performed is proven to have been correct for that input, by showing that they behave in the same way for all possible inputs. Using translation validation is quite effective for proving complex optimisations such as scheduling~\cite{kim04_autom_fsmd,karfa06_formal_verif_method_sched_high_synth,chouksey20_verif_sched_condit_behav_high_level_synth} or code motion~\cite{banerjee14_verif_code_motion_techn_using_value_propag,chouksey19_trans_valid_code_motion_trans_invol_loops}, however, the validation has to be run every time the high-level synthesis 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 could give false positives or false negatives.
+Work is being done to prove the equivalence between the generated hardware and the original behavioural description in C. An example of a tool that implements this is Mentor's Catapult~\cite{mentor20_catap_high_level_synth}, which tries to match the states in the three adress code (3AC) description to states in the original C code after an unverified translation. This technique is called translation validation~\cite{pnueli98_trans}, whereby the translation that the HLS tool performed is proven to have been correct for that input, by showing that they behave in the same way for all possible inputs. Using translation validation is quite effective for proving complex optimisations such as scheduling~\cite{kim04_autom_fsmd,karfa06_formal_verif_method_sched_high_synth,chouksey20_verif_sched_condit_behav_high_level_synth} or code motion~\cite{banerjee14_verif_code_motion_techn_using_value_propag,chouksey19_trans_valid_code_motion_trans_invol_loops}, however, the validation has to be run every time the high-level synthesis 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 could give false positives or false negatives.
\JW{Some papers to cite somewhere:
\begin{itemize}