From: Matthijs Kooijman Date: Thu, 31 Jul 2008 15:03:27 +0000 (+0200) Subject: Add conclusions and do some misc fixes. X-Git-Tag: Report-final~21 X-Git-Url: https://git.stderr.nl/gitweb?a=commitdiff_plain;h=bda4ad2a7baf347f8bb7239ae998088a6987b73b;p=matthijs%2Fprojects%2Finternship.git Add conclusions and do some misc fixes. --- diff --git a/Report/Main/Conclusions.tex b/Report/Main/Conclusions.tex index 3480496..845d7b2 100644 --- a/Report/Main/Conclusions.tex +++ b/Report/Main/Conclusions.tex @@ -1,2 +1,35 @@ \chapter{Conclusions} -This chapter will give a number of conclusions. +During this internship, I have of course learned a lot. While a large part of +these lessons are very practical in nature (from how working in a company works +to how to solve specific coding problems), there are also a number of higher +level observations to be made. + +For example, I have found that the main challenge in solving a problem, is +defining the actual problem you want to solve. This is clearly visible in the +specification of MontiumC: If you don't know what the goals are, you can't +really work towards them. But, on a smaller scale, this also holds on a smaller +scale. When, during coding you encounter a problem, it's often easy to try to +solve that problem. However, after stacking a few small solutions on top of each +other, things get complicated real fast. Then, it helps to take a step back and +try to find the bigger problem you are trying to solve, and evaluate +subsolutions in that perspective. + +During my (limited amount of) work with the new hardware design, it became +quickly apparent that trying to design the hardware in an optimal way, was +completely impossible (when trying to stay within area and power constraints). +The most important issue in this design is finding the balance between two sides +of a tradeoff, which was quite often hardware vs compiler complexity. Especially +this last issue makes it very clear that when designing hardware, the supporting +tooling should be designed in parallel, to prevent the tooling from needing to +be overly complex. + +These limitations are also visible when working with the old hardware: The +hardware poses a lot of limitations on its input, which makes it quite hard to +build a proper compiler, that can reliably compile anything that it is supposed +to. Again, adapting the hardware to support the compiler, has the potential to +make the compiler considerably less complex and more reliable, at the cost of +larger hardware complexity, area and power consumption. + +All in all, I feel that this internship has worked out quite well. The people +were cooperating, the job was fun yet challenging and the result is +well-received. diff --git a/Report/Main/Context/LLVM.tex b/Report/Main/Context/LLVM.tex index e75166b..9d14cbc 100644 --- a/Report/Main/Context/LLVM.tex +++ b/Report/Main/Context/LLVM.tex @@ -16,6 +16,11 @@ code for: \end{itemize} In addition, the LLVM project provides two frontends for generating LLVM IR: -llvm-gcc, which uses gcc to compile a lot of languages with a LLVM backend (from +llvm-gcc, which uses gcc to compile a lot of languages with an LLVM backend (from the gcc point of view) and clang, which is a completely new project designed to parse and emit LLVM IR for all c-like languages (C, ObjC, C++). + +From the LLVM project, we use a number of parts. In section \ref{MontiumC}, we +saw that clang frontend is used directly in the Montium frontend. Also, a lot of +transformations from the LLVM project are used. Lastly, a number of small +library functions and components are used in the frontend. diff --git a/Report/Main/Context/Montium.tex b/Report/Main/Context/Montium.tex index 3556d5f..cd45205 100644 --- a/Report/Main/Context/Montium.tex +++ b/Report/Main/Context/Montium.tex @@ -1,12 +1,12 @@ \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} @@ -27,7 +27,7 @@ flow. 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. @@ -48,19 +48,18 @@ Montium program. \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. @@ -68,15 +67,15 @@ 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 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. @@ -95,9 +94,11 @@ 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. +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. @@ -105,5 +106,5 @@ 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. diff --git a/Report/Main/Context/MontiumC.tex b/Report/Main/Context/MontiumC.tex index 828f3f2..d3da01a 100644 --- a/Report/Main/Context/MontiumC.tex +++ b/Report/Main/Context/MontiumC.tex @@ -1,4 +1,5 @@ \section{MontiumC} +\label{MontiumC} Since having just a piece of hardware is not enough, we also need some way to program the Montium. To this end, the MontiumC language was created. The MontiumC language is a language very similar to C. It allows very fine grained @@ -10,13 +11,19 @@ therefore a valid C program as well. This is one of the strong points of MontiumC: By using a normal C compiler, a MontiumC program can be functionally simulated on normal hardware. +On the other hand, MontiumC defines a number of special functions which are +mapped onto the Montium ALU when compiling with the montium-specific +backend. When compiling with a normal C compiler, these functions are +implemented by a library implemented in C. + Figure \ref{CompilingMontiumC} show the flow for compiling a MontiumC program into a Montium binary file, which can be loaded directly onto a Montium. The process is roughly divided into two parts (each of which corresponds to a different program in the compiler suite): The frontend and the backend. The frontend takes in a MontiumC program and turns it into a lower level -description of the program. The frontend is responsible for mapping higher level +description of the program (LLVM Intermediate Representation, see the next +section). The frontend is responsible for mapping higher level C constructs onto simpler instructions, for canonicalizing and simplifying the code. These canonicalizations and simplifications ensure that the backend can be kept simpler and does not have to deal with all the complexities of the original diff --git a/Report/Main/Context/Recore.tex b/Report/Main/Context/Recore.tex index f8e1a41..6631a70 100644 --- a/Report/Main/Context/Recore.tex +++ b/Report/Main/Context/Recore.tex @@ -1,10 +1,10 @@ \section{Recore Systems} -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 Systems is a relatively young semiconductor 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 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 @@ -14,6 +14,6 @@ components are still in a development stage, but already used internally and by the University of Twente. The activities of Recore and the employees working on them are roughly divisible -into three camps: Hardware design, tooling development and DSP engineering. This -distinction is not a very strict or physical one: most work is the result of a -coordinated effort. +into three disciplines: Hardware design, tooling development and DSP +engineering. This distinction is not a very strict or physical one: most work is +the result of a coordinated effort. diff --git a/Report/Main/Future.tex b/Report/Main/Future.tex index 16c2a54..842900c 100644 --- a/Report/Main/Future.tex +++ b/Report/Main/Future.tex @@ -1,4 +1,5 @@ \chapter{Future work} +\ref{FutureWork} This chapter will describe outstanding tasks and issues. \section{Verifiers} @@ -14,6 +15,7 @@ the specifications. Apart from improving user feedback, this will also greatly help to fine tune the specifications and find bugs in the frontend. \section{Debug info preservation} +\ref{PreserveDebug} Currently, transformation passes are mostly ignorant about debugging info, they treat it as ordinary code. Since debugging info is added to LLVM code by means of special function calls and transformations by default assume that an unknow diff --git a/Report/Main/Introduction.tex b/Report/Main/Introduction.tex index 36e5c67..7ce3239 100644 --- a/Report/Main/Introduction.tex +++ b/Report/Main/Introduction.tex @@ -15,5 +15,8 @@ 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 third chapter lists a number of tasks that are still unfinished and future +work. + The last chapter provides a number of conclusions about my internship and the work performed. diff --git a/Report/Main/Problems/Assignment.tex b/Report/Main/Problems/Assignment.tex index 440a8b8..b87711c 100644 --- a/Report/Main/Problems/Assignment.tex +++ b/Report/Main/Problems/Assignment.tex @@ -6,8 +6,14 @@ changes and transformations. The original assignment defined a few subtasks: \begin{enumerate} - \item Evaluating and selecting exisiting transformation passes. + \item Evaluating and selecting existing transformation passes. \item Adding new transformations for Montium specific problems. \item Providing debugging (context) information to the backend to improve backend error reporting. \end{enumerate} + +Of the above tasks, the first two tasks have been mostly completed, while the +last task has produced workable results but still requires some architectural +changes to LLVM to work fully (see section \ref{PreserveDebug}). Apart from +these tasks, a number of other tasks have presented themselves during the +internship. These are also discussed in the next section. diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex index 06bd72c..39806fa 100644 --- a/Report/Main/Problems/Challenges.tex +++ b/Report/Main/Problems/Challenges.tex @@ -1,13 +1,13 @@ \section{Challenges and Solutions} -This section will describe the challenges faced during each of the tasks and the -solutions found for both the task itself and the challenges. +This section will describe the challenges faced during the work I have performed +and the solutions found for both the task itself and the challenges. \subsection{What is MontiumC?} -A critical question popped up during at the beginning of my internship: What is +A critical question popped up at the beginning of my internship: What is MontiumC? Previously, there was no real specification of MontiumC. There was documentation about the functions that could be used, some examples and a lot of personal knowledge in the heads of the Recore employees, but ultimately MontiumC -was "whatever the compiler eats". +was ``whatever the compiler eats''. To be able to create a proper set of transformations, the constraints on the input and output of that transformation process should be properly specified.