From 2bf1ff846a792ef3007fa1e97928697509f318f7 Mon Sep 17 00:00:00 2001
From: Yann Herklotz <git@yannherklotz.com>
Date: Thu, 15 Apr 2021 10:38:53 +0100
Subject: Update the table

---
 algorithm.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'algorithm.tex')

diff --git a/algorithm.tex b/algorithm.tex
index 1d8201d..2241ee6 100644
--- a/algorithm.tex
+++ b/algorithm.tex
@@ -292,7 +292,7 @@ Typically, HLS-generated hardware consists of a sea of registers and RAM memorie
 This memory view is very different to the C memory model, so we perform the following translation. 
 Variables that do not have their address taken are kept in registers, which correspond to the registers in 3AC.
 All address-taken variables, arrays, and structs are kept in RAM.
-The stack of the main function becomes an unpacked array of 32-bit integers, which is translated to a RAM when the hardware description is passed through a synthesis tool.  \vericert{} generates a well-formed RAM template in Verilog to ensure that a RAM is present in the final hardware, performing reads and writes using the signals that the RAM template exposes, instead of directly modifying the memory.
+The stack of the main function becomes an unpacked array of 32-bit integers, which is translated to a RAM when the hardware description is passed through a synthesis tool.  Initially, \vericert{} translates loads and stores to direct accesses to the memory.  An extra compiler pass is added to generate a well-formed RAM template to ensure that a RAM is correctly inferred by the synthesis tool. Loads and stores are performed using the signals that the RAM template exposes, instead of directly modifying the array.
 Finally, global variables are not translated in \vericert{} at the moment.
 A high-level overview of the architecture can be seen in Figure~\ref{fig:accumulator_diagram}. 
 
-- 
cgit 

