From 60ce3969298b29733ded4ae6bcf166174a2a2487 Mon Sep 17 00:00:00 2001
From: John Wickerson <j.wickerson@imperial.ac.uk>
Date: Fri, 16 Apr 2021 09:56:41 +0000
Subject: Update on Overleaf.

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

(limited to 'verilog.tex')

diff --git a/verilog.tex b/verilog.tex
index e0d1257..b97c6e7 100644
--- a/verilog.tex
+++ b/verilog.tex
@@ -125,7 +125,7 @@ This translation is represented in Figure~\ref{fig:memory_model_transl}, where \
 \begin{figure}
   \centering
   \includegraphics[width=0.5\linewidth]{diagrams/memory_model.pdf}
-  \caption{Change in the memory model during the translation of 3AC to HTL.  This is immediately after the assignment to the array}\label{fig:memory_model_transl}
+  \caption{Change in the memory model during the translation of 3AC to HTL.  This is immediately after the assignment to the array.\YH{TODO: Update diagram}}\label{fig:memory_model_transl}
 \end{figure}
 
 However, in practice, assigning and reading from an array directly in the state machine will not produce a memory in the final hardware design, as the synthesis tool cannot identify the array as having the necessary properties that a RAM needs, even though this is the most natural formulation of memory.  Even though theoretically the memory will only be read from once per clock cycle, the synthesis tool cannot ensure that this is true, and will instead create a register for each memory location.  This increases the size of the circuit dramatically, as the RAM on the FPGA chip will not be reused.  Instead, the synthesis tool expects a specific template that ensures these properties, and will then transform the template into a proper RAM during synthesis.  Therefore, a translation has to be performed from the naive use of memory in the state machine, to a proper use of a memory template.
-- 
cgit 

