\section{Montium Tile Processor}
The Montium Tile Processor (Montium) is the main product of Recore Systems. It
is a reconfigurable processor that is aimed for inclusion in a tiled,
-heterogenous multi- or manycore system on chip (SoC), connected to other tiles
-and the outside world through a network on chip (NoC).
+heterogenous multi- or manycore System-on-Chip (SoC), connected to other tiles
+and the outside world through a Network-on-Chip (NoC).
-The Montium has a number of fundamental differences with "regular" processors
+The Montium has a number of fundamental differences with ``regular'' processors
and DSP engines, that make it both interesting and challenging to program for
-both application programmers and compilers.
+both application programmers and compiler designers.
\begin{figure}
\epsfig{file=Img/MontiumOverview.eps, width=.5\textwidth}
The Sequencer executes its instructions one by one and controls all other
elements through the configuration registers (CR). To keep the size of sequencer
instructions limited, while not limiting the flexibility of the other elements,
-two levels of configuration registers is introduced. These registers are wide
+two levels of configuration registers are introduced. These registers are wide
and contain multiple sets of input signals to the various multiplexers, function
units, etc.
\subsubsection{Memories}
The Montium contains ten memories (two for each ALU). Each of these memories has
its own Address Generation Unit (AGU), which can generate different memory
-patterns. This means that the instructions or CRs never contain direct memory
+address patterns. This means that the instructions or CRs never contain direct memory
addresses, only modifications to the current address. Each memory simply reads
from its current address and offers the value read to the interconnect (which
can then further distribute it to wherever it is needed). Writing works in the
-same way (though a memory can only read or written in the same cycle TODO: Is
-this true?).
+same way (though a memory can only be read or written to in the same cycle).
\subsubsection{ALU's}
The main processing elements of the Montium are its 5 ALU's. Each of them has
four (16 bit) inputs, each with a number of input registers. Each ALU contains a
-number of function units, a multiplier, a few adders and some miscelaneous
+number of function units, a multiplier, a few adders and some miscellaneous
logic. Each of the elements in the ALU can be controlled seperately and data can
-be routed in different ways through configuration of multiplexers inside the
+be routed in different ways by configuration of multiplexers inside the
ALU. The ALU has two output ports, without registers. Additionally, there is a
connection from each ALU to its neighbour.
in a single cycle, to arrive at the outputs before the end of the cycle. This
means that the ALU can perform a lot of computation in a single clock cycle. For
example, using four of the five ALU's, an FFT butterfly operation (two complex
-multiplications and four complex additions TODO: Right?) can be exected in a
+multiplications and four complex additions) can be exected in a
single clock cycle. The downside of this approach is that the data will have a
-long path to travel over, which limits the clock speed of the design.
+long path to travel, which limits the clock speed of the design.
\subsubsection{CCU}
The CCU controls communication with the external world, usually a
-network-on-chip. During normal operations, the CCU can take values from the
+NoC. During normal operations, the CCU can take values from the
interconnect and stream them out onto the NoC, or vice versa. Additionally, the
-CCU can be used from external to the Montium to start and stop execution and
+CCU can be used from outside the Montium to start and stop execution and
move configuration registers, sequencer instructions and memory contents into
and out of the Montium.
In particular, the ALUs are capable of performing a large number of operations
in a single cycle, but since they operate sequentially, this severly limits
clock speeds. In the new design, the number of ALUs is reduced, but each ALU is
-subdivided in multiple parallel-operating function units.
+subdivided in multiple parallel operating function units. Also, the Montium has
+only very limited support for control flow, making it hard to program it for
+data dependent control and synchronization, which ask for improvements.
-This approach requires computations to be properly pipelined to be efficiently
+This approach requires computations to be properly pipelined to efficiently
use all those function units in parallel, but since data only travels through
only a single function unit in each cycle, this allows for much higher clock
speeds than the old design.
During my internship I have mainly been working with the old Montium design, and
unless otherwise stated, that is what is meant when referring to the "Montium".
Some of the work has been done with the new design in mind, but only during the
-final weeks of my internship I have been involved with the new design enough to
-see most of the picture. See section \ref{Pipelining} for more details.
+final weeks of my internship I have been actually working with the new design.
+See section \ref{Pipelining} for more details.
projects / matthijs / projects / internship.git / blobdiff