Add introduction, a piece about Recore and a piece about the Montium.
authorMatthijs Kooijman <kooijman@eris.recoresystems.com>
Wed, 16 Jul 2008 09:26:52 +0000 (11:26 +0200)
committerMatthijs Kooijman <kooijman@eris.recoresystems.com>
Wed, 16 Jul 2008 09:26:52 +0000 (11:26 +0200)
Report/Main/Context/Montium.tex
Report/Main/Context/Recore.tex
Report/Main/Introduction.tex

index 18272ca7553da01ebe4d3f1f80800a28efffcac1..7fc8145fb39cf55dee7edbbe9420404ee508f366 100644 (file)
@@ -1,4 +1,97 @@
 \section{Montium Tile Processor}
-This section describes the Montium Tile Processor (Montium) in moderate detail.
-It is not meant to be a full spec, but it provides the context necessary for
-understanding the next sections and getting a feel for the challenges involved.
+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-core system on chip (SoC), connected to other tiles and the
+outside world throug a network on chip (NoC).
+
+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.
+
+\begin{figure}
+  \epsfig{file=Img/MontiumOverview.eps, width=.5\textwidth}
+  \caption{Overview of the Montium design}
+\end{figure}
+
+\subsection{Overall design}
+The Montium is built from a few parts. The central part is the interconnect,
+which ties memories, Arithmetic and Logic Units (ALU) and the Communication
+and Configuration Unit (CCU) together. The memories store data locally, the
+ALU's process data and the CCU moves data and configuration on and off the
+Montium. Furthermore, the sequencer is the closest thing to a normal processor
+in the Montium: It accepts and executes instructions one by one, is capable of
+performing (conditional) jumps and some other limited control flow. 
+
+\subsubsection{Sequencer}
+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,
+a level of configuration registers is introduced. These registers are wide and
+contain multiple sets of input signals to the various multiplexers, function
+units, etc.
+
+The sequencer instructions in turn contain indices into these configuration
+registers. This way, every sequencer instruction can select a configuration for
+the entire Montium for the cycle during which the instruction is executed. This
+also means that the Montium is reconfigured on every cycle, for maximum
+flexibility and performance.
+
+\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 CR's 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 write 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
+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
+ALU. The ALU has two output ports, without registers.
+
+The ALU also has no internal registers, so data travels through the entire ALU
+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) can be exected in a single clock
+cycle.
+
+\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
+interconnect and stream them out onto one of the lanes of the NoC, or vice
+versa. Additionally, the CCU can be used from external to the Montium to start
+and stop execution and move configuration registers, sequencer instructions and
+memory contents into and out of the Montium.
+
+\subsubsection{Interconnect}
+The central part of the Montium is the interconnect, which is a mostly connected
+crossbar of lines. There are a total of 10 global busses in the interconnect, to
+which every input and output port of the various components can be connected.
+This way, every output of the memories, ALU's and CCU can be routed to every
+input (provided that there are enough global busses). Additionally, each pair of
+memories belonging to a specific ALU can be routed directly to the inputs and
+outputs of that ALU, without requiring a global bus.
+
+\subsection{Design changes}
+Currently, the Montium design is experiencing a major overhaul. During work with
+the original design, a number of flaws or suboptimal constructs have been found.
+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.
+
+This approach requires computations to be properly pipelined to be efficiently
+use all those function units in parallel, but since data only travels through 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.
index bc9c065f23b3396644b5ef963966c674ebbedb58..fb8b16435a03dc739d427dd3202583ee365e1bbf 100644 (file)
@@ -1,2 +1,14 @@
 \section{Recore Systems}
-This section briefly describes Recore Systems and its activities.
+Recore Systems is a relatively young IT company based in Enschede, the
+Netherlands. It emerged as the result of research at the University of Twente
+and focuses on developing hardware IP blocks for use in semiconductor devices.
+The main product of Recore is to be the Montium Tile Processor, a low energy,
+high performance reconfigurable processor aimed at low-power DSP applications.
+The Montium will be discussed in more detail in the next section.
+
+Recore aims to provide a full solution for semiconductor manufactures and their
+customers, by providing IP blocks such as the Montium, tools for working with
+them such as a compiler, an IDE and simulation environments and sample programs
+and DSP libraries to ease application development. Currently, all of these
+components are still in a development stage, but already used internally and by
+the University of Twente.
index 2c3065e31eaf153342c7d407c8eb824b9bebe715..c2e9e75ce3eb3b0b773c6482cff658cabe469b62 100644 (file)
@@ -1,2 +1,10 @@
-\chapter{Introduction}
-This chapter introduces the subject of this report and lays out its structure.
+\chapter*{Introduction}
+This report describes my internship at Recore Systems. 
+The first chapter provides some context, such as a description of Recore
+Systems, their products and the tools I have been using. 
+
+The second chapter provides an overview of the assignment and the challenges
+faced when completing it.
+
+The last chapter provides a number of conclusions about my internship and the
+work performed.