Commit 95bedd8a authored by Jules Saget's avatar Jules Saget
Browse files

Implemting Carl's comments

parent 19d4a36f
......@@ -223,7 +223,7 @@ Here is how they are defined:
S x y z & \rightarrow_\beta x z (y z) \\
\end{align*}
Their behaviour is shown on figure \ref{fig:ski}.
Their behaviour is shown in Fig~\ref{fig:ski}.
Note that \emph{K} and \emph{I} create an \emph{indirection node} (represented
by the $=$ symbol), which is similar to a symbolic link in Linux.
These nodes ensure laziness is not lost \cite{Pey87}.
......@@ -244,8 +244,7 @@ Consider this $\lambda$-expression:
\]
After compiling this to combinators using a standard “brackecting” approach
\cite{Pey87}, we would obtain the leftmost graph shown in figure
\ref{fig:gr_ex}.
\cite{Pey87}, we would obtain the leftmost graph shown in Fig~\ref{fig:gr_ex}.
\begin{figure}[ht]
\centering
......@@ -281,7 +280,9 @@ The different types include:
next part of the integer. More details in \ref{subsubsec:api}.
\end{itemize}
Apart from indirection node which are handled directly by the memory controller, all nodes are decoded by the reduction engine and processed accordingly.
Apart from indirection node which are handled directly by the memory
controller, all nodes are decoded by the reduction engine and processed
accordingly.
When it detects the application of a primitive function to two or three
arguments, it sends the data to the ALU to be processed.
......@@ -310,7 +311,7 @@ Suppose now that the initial design has a heater that
can change the temperature in the room by at most one degree per minute
and that all computations are performed with 8 bits 2's complement arithmetic.
With some effort, it is not too difficult to show that this IoT controlled
system will guarantee that the temperature never go above 33°C.
system will guarantee that the temperature never goes above 33°C.
Suppose now that the heater is replaced with a more efficient one that
can raise the temperature 3°C per minute.
......@@ -420,7 +421,7 @@ February 2020.
A tool paper about VossII has been submitted to Memocode '20 \cite{VossII}.
The whole CEPHALOPODE processor is written in \emph{fl}.
To see an example of how VossII works, look at the code in listing
To see an example of how VossII works, look at the code in Listing
\ref{fl:andor}.
This code implements a part of the logical unit which will be described in
\ref{subsec:logical}.
......@@ -460,16 +461,17 @@ let v_AO = STE_debug ckt_AO;
\end{listing}
As you can see, the syntax is fairly similar to a typical functional language.
The \texttt{ENUM} construction (as well as \texttt{TYPE} or \texttt{STRUCT})
As can be seen, the syntax is fairly similar to a typical functional language.
The \texttt{ENUM} constructor (as well as \texttt{TYPE} or \texttt{STRUCT})
allows the user to define a new hardware type, similar to what can be done in
C.
The first function features record types (with access to the field
\texttt{int} of the node \texttt{node\_Int\_false}).
For more complicated modules (such as \texttt{AND\_OR\_unit}), you first
declare the interface of the module before describing its content with
\texttt{CELL}, which takes a name and a list of \emph{wirings}.
For more complicated modules (such as \texttt{AND\_OR\_unit}), the interface of
the module is first described before the content is defined.
The content is defined with \texttt{CELL}, which takes a name and a list of
\emph{wirings}.
A \emph{wiring} can be either a direct affection (the wire \texttt{node\_out}
is directly connected to the output of the \texttt{IF THEN ELSE}
construct\footnote{This consctruct is in fact a multiplexer, as shown in
......@@ -502,8 +504,8 @@ let shadok =
Finally, each circuit can be drawn with \texttt{STE\_debug} and shown to the
user.
In that case, calling \texttt{v\_AO} will result in the window on figure
\ref{fig:andor}.
In that case, calling \texttt{v\_AO} will result in the window in
Fig~\ref{fig:andor}.
\begin{figure}[ht]
\centering
......@@ -525,9 +527,9 @@ to describe the different states a circuit will go through.
FSMs are in fact finite automata that read inputs from the rest of the circuit
and output a state name.
To showcase a concrete example, imagine some module wants to read data from
memory.
The process is the following:
To showcase a concrete example, imagine that some module wants to read data
from memory.
The process would be as follows:
\begin{enumerate}
\item[IDLE] At the begining, the reading module does nothing until prompted
by another module to do something.
......@@ -548,10 +550,9 @@ The process is the following:
that the reading task has been completed.
\end{enumerate}
As you can see, this process is clearly divided into four steps with a clear
condition to go from one step to another: this process can be represented by a
FSM.
Such a FSM is shown on figure \ref{fig:4ph}.
This process is divided into four distinct steps with a clear condition to go
from one step to another: this process can be represented by a FSM.
Such a FSM is shown in Fig~\ref{fig:4ph}.
For more details on 4 phase handshake protocols, see \cite{category}.
\begin{figure}[ht]
......@@ -562,7 +563,7 @@ For more details on 4 phase handshake protocols, see \cite{category}.
\end{figure}
Using VossII, we could use the built in \texttt{Moore\_FSM} function to
describe the above FSM, as shown in listing \ref{fl:4ph}.
describe the above FSM, as shown in Listing \ref{fl:4ph}.
\begin{listing}[ht]
\small
......@@ -575,14 +576,14 @@ Moore_FSM "handshaker" clk state (reset --- IDLE) [
DONE --- '~' start --- IDLE
]
\end{minted}
\caption{Code implementing the FSM on figure \ref{fig:4ph}}
\caption{Code implementing the FSM in Fig~\ref{fig:4ph}}
\label{fl:4ph}
\end{listing}
A FSM in \emph{fl} is in fact a list of triplets, where the two first elements
(a state and a condition) give a rule to go to the last element.
As you may guess, it is far easier to think of FSMs under their visual form
As one may guess, it is far easier to think of FSMs under their visual form
rather than their list form.
In fact, the design process is done exclusively on paper, and the list version
is just a transcription of the visual form\footnote{This is not only true in my
......@@ -606,7 +607,7 @@ would let us design FSMs in visual mode and that would directly output
The tool itself was mainly developed by Jeremy Pope \cite{stately-git}, but Carl
Seger and I provided most of the user feedback.
Moreover, most of the design ideas (like the virtual states we will discuss
in \ref{subsec:comparator}) came up during out meetings.
in \ref{subsec:comparator}) came up during our meetings.
This is why the three of us are listed on the paper we submited for
Stately \cite{stately}.
......@@ -640,8 +641,8 @@ Here is a list of all the primitive functions we want our processor to perform:
\emph{Note: most of this subsection is taken from \cite{CEPHALOPODE}}
To illustrate our approach to implementing arbitrary precision in hardware,
I will start with the comparator unit due to its relative
simplicity\footnote{As you may remember from \ref{subsubsec:api},
we will start with the comparator unit due to its relative
simplicity\footnote{As the reader may recall from \ref{subsubsec:api},
the comparison is where our endiannesn choice is the least relevant.
The relevance of our choice will appear when describing arithmetical
operations.}.
......@@ -669,7 +670,7 @@ When one of the numbers end, there are two possibilities
To follow the logic of the comparator, it is useful to draw a finite state
machine that describes how the unit work; a visual description of the
finite state machine is shown in figure~\ref{fig:comp_fsm}.
finite state machine is shown in Fig~\ref{fig:comp_fsm}.
\begin{figure}[ht]
\centering
......@@ -764,7 +765,7 @@ unfinished) of both inputs (\texttt{A} and \texttt{B}).
\paragraph{First example}
Consider the simple example given in table~\ref{tab:arith_ex_simple}.
Consider the simple example given in Table~\ref{tab:arith_ex_simple}.
The table should be read from left to right as:
\begin{itemize}
\item[State:] The state we are in (see FSM on Fig.~\ref{fig:addsub_fsm}).
......@@ -961,14 +962,14 @@ Usually, a multiplication is done in two distinct steps:
Unfortunately for us, this process requires to store a partial result for each
digit (or in our case, \emph{chunks}) of the first number.
However, we do not now the size of a number beforehand, and we have no
However, we do not know the size of a number beforehand, and we have no
guarantee on its maximum size.
That is why I decided to merge both processes: instead of storing different
lines, we store only one partial result that we update at every step.
This means that, contrary to the regular multiplication, we will have to go
back to previous partial results and update them.
The FSM of this process can be found in figure in figure \ref{fig:mul_fsm}.
The FSM of this process can be found in Fig~\ref{fig:mul_fsm}.
The three nested loops can be seen, with a virtual \texttt{LOOP\_CHECK} at the
end of each one.
......@@ -1009,7 +1010,7 @@ Preparing the address is fairly simple as well:
\item in any other case, we need to allocate a new address.
\end{itemize}
The whole process is examplified in table \ref{tab:mul_2by2}, with the
The whole process is examplified in Table~\ref{tab:mul_2by2}, with the
multiplication of \texttt{010·111} (23) by \texttt{011·111} (31).
The table differs a bit from previous examples:
\begin{itemize}
......@@ -1025,13 +1026,13 @@ The table differs a bit from previous examples:
\input{tables/mul_2by2.tex}
This example is a bit complex, but in simpler cases the process is very similar
to the addition process.
This example might appear slightly complex, but in simpler cases the process is
very similar to the addition process.
Despite its apparent complexity, the example is pretty straightforward.
Look at what happens when \texttt{B} has ended, \emph{ie} when \texttt{A} is
Consider what happens when \texttt{B} has ended, \emph{i.e.} when \texttt{A} is
read for the second time.
At this point, we need to write to a chunk that as already been written, but
At this point, we need to write to a chunk that has already been written, but
not start from the very begining: there is an \emph{offset}.
This means we need to remember an address to return to when moving on to the
next chunk of \texttt{A}.
......@@ -1040,10 +1041,10 @@ next chunk of \texttt{A}.
\label{subsec:cleaning}
The cleaning unit is not very complex.
It simply reads through integers after an arithmetical operation has been
It simply reads through integers after an arithmetic operation has been
performed, keeps the address of the last relevant chunks, and overwrite this
chunks to remove any link to other chunks.
The FSM of the cleaning unit is available on figure \ref{fig:clean_fsm}.
The FSM of the cleaning unit is available in Fig~\ref{fig:clean_fsm}.
\begin{figure}[ht]
\centering
......@@ -1052,7 +1053,7 @@ The FSM of the cleaning unit is available on figure \ref{fig:clean_fsm}.
\label{fig:clean_fsm}
\end{figure}
This FSM introduce a the $(\texttt{PRE\_READ}, \texttt{WAIT\_READ},
This FSM introduce the $(\texttt{PRE\_READ}, \texttt{WAIT\_READ},
\texttt{READ})$ triplet.
This is a shortcut on handshake protocols: we immediately leave the
\texttt{READ} state after obtaining the relevant information.
......@@ -1088,7 +1089,7 @@ operation to determine the result:
else it is \texttt{B} and we return an indirection node (see
\ref{subsec:datarep}) to \texttt{B};
\item[AND] conjonction is similar to disjuntion\footnote{They are actually
the same module, shown in listing \ref{fl:andor} and in figure
the same module, shown in Listing \ref{fl:andor} and in Fig~
\ref{fig:andor}.};
\item[COND] it is clear in the case of \emph{if then else} constructs, and
the module just returns an indirection to the right node.
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment