summaryrefslogtreecommitdiffstats
path: root/algorithm.tex
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2020-07-17 16:06:01 +0100
committerYann Herklotz <git@yannherklotz.com>2020-07-17 16:06:01 +0100
commit93d5228889bc993abf7d84d074eca56725d17826 (patch)
tree71e370b22c037f0e6d0134bfc3a6ea7b9566f81e /algorithm.tex
parentb7fe1c77fa2536d795565733c5ce9c3889cef872 (diff)
downloadoopsla21_fvhls-93d5228889bc993abf7d84d074eca56725d17826.tar.gz
oopsla21_fvhls-93d5228889bc993abf7d84d074eca56725d17826.zip
Fix abstract
Diffstat (limited to 'algorithm.tex')
-rw-r--r--algorithm.tex4
1 files changed, 2 insertions, 2 deletions
diff --git a/algorithm.tex b/algorithm.tex
index c29ad77..5e7868d 100644
--- a/algorithm.tex
+++ b/algorithm.tex
@@ -27,7 +27,7 @@
\caption{Verilog backend branching off at the RTL stage.}\label{fig:rtlbranch}
\end{figure}
-This section covers the main architecture of the HLS tool, and how the backend was added to CompCert.
+This section covers the main architecture of the HLS tool, and the way in which the backend was added to CompCert.
CompCert is made up of 11 intermediate languages in between the Clight input and the assembly output. These intermediate languages each serve a different purpose and contain various different optimisations. When designing a new backend for CompCert, it is therefore crucial to know where to branch off and start the hardware generation. Many of the optimisations that the CompCert backend performs are not necessary when generating custom hardware and not relying on a CPU anymore, such as register allocation or even scheduling. It is therefore important to find the right intermediate language so that the HLS tool still benefits from many of the generic optimisations that CompCert performs, but does not receive the code transformations that are specific to CPU architectures.
@@ -67,7 +67,7 @@ Existing HLS compilers usually use LLVM IR as an intermediate representation whe
\caption{Accumulator example translated to a finite state-machine with datapath (FSMD).}\label{fig:accumulator_fsmd}
\end{figure}
-To describe the translation, we start with an example of how to translate a simple accumulator example, which is shown in figure~\ref{fig:accumulator_c}. Using this example, the different stages in the translation can be explained, together with how they were proven.
+To describe the translation, we start with an example of how to translate a simple accumulator example, which is shown in figure~\ref{fig:accumulator_c}. Using this example, the different stages of the translation can be explained, together with the way they were proven.
The first step is to use the CompCert front end passes to convert the C code into RTL, which is the intermediate language that CompCert uses for most of its optimisations. The translation is shown in figure~\ref{fig:accumulator_c_rtl}, where the RTL code is depicted in figure~\ref{fig:accumulator_rtl}. At the RTL stage, many of CompCert's normal optimisations passes, such as deadcode elimination or common subexpression elimination (CSE) can be applied to reduce the RTL as much as possible. The optimised RTL is then translated to HTL, consisting of a finite state-machine representation of the RTL code. This representation maps directly to hardware and it therefore transformed to Verilog afterwards. The translation from RTL to HTL is the main step in converting the software representation of the code into a hardware representation of the code. The following sections will go over the details of the transformation of each pass.