diff options
author | Yann Herklotz <git@yannherklotz.com> | 2021-02-24 14:14:29 +0000 |
---|---|---|
committer | Yann Herklotz <git@yannherklotz.com> | 2021-02-24 14:14:29 +0000 |
commit | 004b22ea997f4a5b04a06b9b40c3cdea23c455a9 (patch) | |
tree | 997e82f85fa3222e20a6cf76db04f81ce49874f2 | |
parent | 5561c97514b97d524593de9e6b25cd2de4704c7d (diff) | |
download | latte21_hlstpc-004b22ea997f4a5b04a06b9b40c3cdea23c455a9.tar.gz latte21_hlstpc-004b22ea997f4a5b04a06b9b40c3cdea23c455a9.zip |
Add information about flakiness
-rw-r--r-- | main.tex | 4 |
1 files changed, 3 insertions, 1 deletions
@@ -216,7 +216,9 @@ However, \citet{du21_fuzzin_high_level_synth_tools}, for example, show that on a \subsection{A Verified tool can still be flaky and fail} -It is true that a verified tool is still allowed to fail at compilation time, meaning none of the correctness proofs need to hold, as no output was produced. However, this is only a matter of putting more engineering work into the tool to make it reliable and get it to output +It is true that a verified tool is still allowed to fail at compilation time, meaning none of the correctness proofs need to hold, as no output was produced. However, this is only a matter of putting more engineering work into the tool to make it reliable. If a test bench is available, it is also quite simple to check this property, as it just has to be randomly tested without even having to execute the output. + +In addition to that, specifically for an HLS tool taking C as input, undefined behaviour will allow the HLS tool to behave any way it wishes. This becomes even more important when passing the C to a verified HLS tool, as if it is not free of undefined behaviour, then none of the proofs will hold. \section{Guarantees of trusted code} |