% This introduction is far from finalised. The text might seem a bit like rambling without a coherent purpose.

One of the many advantages of software design---when compared to traditional hardware design, is the relative low bar of entry. Anyone with a computer, some time and the right amount of motivation, is able to start working on projects or teach him or herself the ins and outs of various programming languages or theories in programming. This used to be in stark contrast to hardware design. Trying to design custom hardware components or learning about the inner workings of certain components was done in either a strictly theoretical fashion, or in a more involved practical fashion. The first of these tactics typically entails reading up on the needed technical specifications from manuals and applying this to an abstract implementation in the form of diagrams. This way, testing of the functional correctness of a design had to be tested purely based on deduction from this theoretical implementation, without real world testing. Practical testing could also be a possibility, but this came with other disadvantages, like having to buy necessary components, equipment, and needing to have the required technical knowledge to handle said components and equipment.

With the dawn of more capable computational hardware, it becomes more and more feasible to design hardware in a more software-like fashion and test its functionality in a purely software based simulation framework. Applying these techniques to designing and understanding hardware eliminates the need for buying actual hardware, which, like software design, dramatically lowers the bar of entry. 

Apart from this, hardware simulation introduces more possible advantages when compared to using real components. When running more complex components, like integrated circuits, the inner workings are hidden in a black box-like fashion. Without the use of specialised probing equipment, it is impossible to see what goes on inside such parts. With further increased complexity, having a look inside the a used components might even become impossible. By using simulated hardware, 

This research in particular focuses on the simulation of computer system architectures. Central to these architecture is of course the central processing unit of CPU, which is inherently a complex components comprised of a number of discrete components brought together on a single piece of silicon. In order to perform the simulation of such a component, an appropriate description language is needed. In this case, the C++ library SystemC is chosen for the software-based implementation of the simulated system architectures. 

In the end, one might still want to test a hardware design written in software in the real world. Therefore, this project aims to implement a systematic way in which the SystemC-based hardware implementation can be translated to a HDL-based implementation. Such an implementations should in turn be executable of the right FPGA hardware, and, as such, the software-described architecture implementation can be tested in a true hardware context. 

\section{Research question}
In order to fulfil the needs presented in the introduction, a set of solid research questions have been formulated:

\begin{itemize}
    \item How can a system architecture be accurately simulated using a SysteC-based framework?
    \item What systematic approach can be used to visualise the internal structure of a SystemC-based archtitecture in terms of components and data streams?
    \item What communication mechanisms are required to ensure external extensibility of a simulation framework?
    \item What constraints are placed on a SystemC hardware description when this description is to be converted to a VHDL-based description?
\end{itemize}

\section{Outline}
The following writing will introduce the theoretical concepts needed in order to perform this research in chapter 2. Based on this theoretical knowledge, the desired framework is implemented in an iterative fashion. The process of this implementation and the motivations behind specific implementation decisions is described in chapter 3. In chapter 4, results of tests done with the implemented framework are presented. Finally, chapter 5 features concluding remarks, a reflection on the research process of this project and possible future work which might follow from this project.