.gitignore

@@ -24,5 +24,5 @@
 *.o
 *.ghw
 work-*.cf
-main-*
+
 svg-inkscape/

bibliographies/DP.bib

@@ -34,7 +34,6 @@
 	key = {W–670–ORD–4926},
 	month = Jun,
 	year = {1945},
-	author = {John von Neumann},
 	title = {First Draft of a Report on the EDVAC},
 	institution = {United States Army Ordnance Department and the University of Pennsylvania},
 	volume = {1945},
@@ -159,67 +158,3 @@
 	author = {Unknown Author},
 	url = {https://www.nongnu.org/avr-libc/user-manual/pgmspace.html}
 }
-
-@Manual{232mouse,
-	year = {1998},
-	title = {TrackPoint Engineering Specification Version 4.0 Serial Supplement},
-	organization = {IBM Corp.},
-	author = {B. Olyha, J. Rutledge},
-	url = {https://web.stanford.edu/class/ee281/projects/aut2002/yingzong-mouse/media/Serial%20Mouse%20Detection.pdf}
-}
-
-@Manual{laval_parallel,
-	year = {1998},
-	title = {IEEE 1284: Parallel Ports},
-	organization = {Lava Computer MFG Inc.},
-	author = {Unknown author},
-	url = {https://www.lavaports.com/wp-content/uploads/white_papers/ieee1284_parallel_ports.pdf}
-}
-
-@Manual{ac97,
-	year = {1996},
-	title = {Overview ofAudio Codec ‘97},
-	organization = {Intel Corporation},
-	author = {Dan Cox},
-	url = {http://euc.jp/periphs/AC97_OVR.PDF}
-}
-
-@Manual{ibmpc,
-	year = {1984},
-	month = Mar,
-	title = { IBM Personal Computer AT Technical Reference},
-	organization = {International Business Machines Corporation},
-	author = {Various},
-	url = {http://euc.jp/periphs/AC97_OVR.PDF}
-}
-
-@Manual{vga,
-	title = {VGA Student Presentation},
-	organization = {University of Michigan},
-	author = {Chris Knebel Ian Kaneshiro Josh Knebel Nathan Riopelle},
-	url = {https://www.eecs.umich.edu/courses/eecs373/Lec/StudentF18/VGA%20Student%20Presentation.pdf}
-}
-@Manual{iic,
-	year = {2014},
-	month = Apr,
-	title = {I2C-bus specification and user manual},
-	organization = {NXP Semiconductors N.V.},
-	author = {Unknown Author},
-	url = {https://www.nxp.com/docs/en/user-guide/UM10204.pdf}
-}
-@Manual{ddc,
-	year = {2007},
-	month = Dec,
-	title = {VESA Enhanced Display Data Channel (EDDC) Standard},
-	organization = {Video Electronics Standards Association},
-	author = {Unknown Author},
-	url = {https://glenwing.github.io/docs/VESA-EDDC-1.2.pdf}
-}
-@Manual{pca9564,
-	year = {2006},
-	month = Sep,
-	title = {PCA9564 Parallel bus to I2C-bus controller},
-	organization = {Philips Semiconductors},
-	author = {Unknown Author},
-	url = {https://www.nxp.com/docs/en/data-sheet/PCA9564.pdf}
-}

main.auxlock

@@ -1 +0,0 @@
-\def \tikzexternallocked {0}

main.tex

@@ -115,14 +115,14 @@ geschlechtsunabh"angig verstanden werden soll.
 \setcounter{section}{0}
 \pagenumbering{arabic}
 
-\section{Introduction}
-\input{sections/intro.tex}
+%\section{Einleitung}
+%\input{sections/einleitung.tex} TODO
 
 \section{Task description}
 \DP\input{planung/DP/aufgabenstellung.tex}
 
-\section{Organization}
-\DP\input{sections/DP/plan.tex}
+%\section{Planung}
+%\DP\input{planung/DP/planung.tex}
 
 \clearpage
 \pagestyle{fancy}
@@ -203,12 +203,11 @@ geschlechtsunabh"angig verstanden werden soll.
 %\input{sections/Anhang/Pflichtenheft/pflichtenheftMR.tex}
 %
 %\newpage
-\subsection{Schlussfolgerung / Projekterfahrung}
-\input{sections/Anhang/schlussfolgerung.tex}
-\subsection{Projektplanung}
-\DP\input{sections/Anhang/planung.tex}
-\subsection{Projektterminplanung}
-\DP\input{sections/Anhang/Projektterminplanung/projektterminplanungDP.tex}
+%\subsection{Schlussfolgerung / Projekterfahrung}
+%\input{sections/Anhang/schlussfolgerung.tex}
+
+%\subsection{Projektterminplanung}
+%\MR\input{sections/Anhang/Projektterminplanung/projektterminplanungMR.tex}
 
 \clearpage
 %\subsection{Arbeitsnachweis Diplomarbeit}

preamble.tex

@@ -166,13 +166,14 @@
 \usepackage{tabularx} % Allows the H floating option
 \usepackage[headheight=0mm, margin=2.5cm]{geometry}
 %%% MR-packages:
-\usepackage[
+\usepackage{hyperref}
+\hypersetup{
 	pdfauthor={Daniel Plank, Armin Brauns},
 	pdftitle=YARM,
 	pdfproducer=5ABHEL,
 	bookmarks=true,
 	pdfcreator=xelatex,
-]{hyperref}
+}
 
 \usepackage{tikz,pgfplots}
 	\usetikzlibrary{plotmarks}
@@ -399,9 +400,6 @@ minimum height=1cm, align=center, text width=3cm, draw=black, fill=blue!30]
       {]}{{{\color{delim}{]}}}}{1},
 }
 
-\usepgfplotslibrary{external}
-\tikzexternalize
-
 \usepackage{titling}
 \usepackage{datetime}
 \yyyymmdddate

sections/Anhang/Projektterminplanung/projektterminplanungDP.tex

@@ -1,54 +0,0 @@
-\subsubsection{Meilensteine}
-
-\paragraph{Brauns}
-Tabelle \ref{tab:mst_brauns} zeigt die zu Projektbeginn festgelegten Meilensteine.
-\begin{table}[H]
-	\centering
-	\begin{tabular}{| c | r |}
-		\hline
-		\textbf{Datum} & \textbf{Meilenstein}\\
-		\hline
-		\hline
-		21.10.2019 & Pflichtenheft, Grobdesign, Testplan, Core-Grundstruktur \\
-		\hline
-		17.12.2019 & Komplettes Core-Simulationsdesign\\
-		\hline
-		21.01.2020 & Simpler SoC (core+memory+LEDs) und Implementierung in FPGA \\
-		\hline
-		18.02.2020 & Anbindung an diskrete Peripherie\\
-		\hline
-		10.03.2020 & UART-Bootloader\\
-		\hline
-	\end{tabular}
-	\caption{Meilensteine Brauns Armin}
-	\label{tab:mst_brauns}
-\end{table}
-
-\paragraph{Plank}
-
-Tabelle \ref{tab:mst_plank} zeigt die zu Projektbeginn festgelegten 
-Meilensteine. Der Meilensteininhalt wurde nach der Aufgabenstellung zugeteilt,
-die Meilensteintermine wurden vom Betreuer festgelegt.
-
-\begin{table}[H]
-	\centering
-	\begin{tabular}{| c | r |}
-		\hline
-		\textbf{Datum} & \textbf{Meilenstein}\\
-		\hline
-		\hline
-		22.10.2019 & Pflichtenheft, Grobdesign, Testplan, Beschaffung der Unterlagen\\
-		\hline
-		10.12.2019 & Serielle Schnitstelle\\
-		\hline
-		14.01.2020 & 8-Bit-Parallelport\\
-		\hline
-		12.02.2020 & Dokumentation\\
-		\hline
-		10.03.2020 & 4-Bit-DAC mit R-2R-Netz\\
-		\hline
-	\end{tabular}
-	\caption{Meilensteine Plank Daniel}
-	\label{tab:mst_plank}
-\end{table}
-

sections/Anhang/schlussfolgerung.tex

@@ -1,8 +0,0 @@
-Aus der Projektimplementierung konnten viele Lehren gezogen werden. Messungen
-welche mittels ses Analog Discoverys durchgeführt wurden sind bis zu ungefähr 
-1MHz frequenz gut zu gebrauchen werden danach jedoch sehr stark fehlerhaft. Alle
-Bauteile in THT Bauform zu verwenden vereinfachte Messungen am Steckbrett 
-erheblich, jedoch werden diese bei hohen Frequenzen unzuverlässig. Viele
-Implementationsdetails wurden durch mündlich übergebene Hinweise  verbessert
-was zeigt wie wichtig zwischenmenschliche Kommunikation in technischen Bereichen
-ist.

sections/DP/CASE_BACKPLANE/main.tex

@@ -5,7 +5,7 @@ straight through. For this purpose a backplane was chosen where DIN41612
 connectors can be used. These connectors were chosen for their large pin count
 (96 pins) and their availability. The backplane connects all 96-pins straight
 through. With the 6 outer left and right pins connected for VCC and ground
-as can be seen in Figure \ref{fig:schem_back_conn}.
+as can be seen in figure \ref{fig:schem_back_conn}.
 
 \begin{figure}[H]
 	\includegraphics[width=\textwidth, angle=0]{schem_pdf/backplane_conn.pdf}
@@ -18,7 +18,7 @@ as can be seen in Figure \ref{fig:schem_back_conn}.
 In constrast to other systems using this backplane no termination resistors
 were used. This makes the bus more prone to refelctions, however these were not
 a problem during development with the maximum transmission rate of 1MHz, as can
-be seen in the sample recording in Figure \ref{fig:reflex}
+be seen in the sample recording in figure \ref{fig:reflex}
 
 \begin{figure}[H]
 \begin{tikzpicture}
@@ -39,7 +39,7 @@ be seen in the sample recording in Figure \ref{fig:reflex}
 	\label{fig:reflex}
 \end{figure}
 
-The ripple  seen in Figure \ref{fig:reflex} is most likely due to
+The ripple  seen in figure \ref{fig:reflex} is most likely due to
 the sample rate of the Oszilloscope, which is around 10Mhz after an average
 filter has been applied. The measurement was performed on the finished project
 with all cards installed.

sections/DP/PARALLELBUS/main.tex

@@ -52,73 +52,50 @@ be 8 bit, which is multiple times the amount of needed address space, but
 is the smallest addressable unit on most microcontroller architectures and
 therefore easy to program with. The address bus is unidirectional.
 
-\subsubsection{Data Bus}
+\subsection{Data Bus}
 
 The data bus contains the actual data to be stored to and read from registers.
 The data bus is, as well on most systems a multiple of 16 bits wide, but for the
 same reasons as the data bus, was shrunk down in our case to 8 bits. The data
 bus is bidirectional.
 
-\subsubsection{Control Bus}
+\subsection{Control Bus}
 
 Control bus is a term which referes to any control lines (such as read and write
 lines or clock lines)  which are neither address nor data bus. The control bus
 in our case is 5 bits wide and consists of:
 
-\begin{table}[H]
-	\centering
-	\begin{tabular}{| c | r |}
-		\hline
-		\textbf{Signal} & \textbf{Description}\\
-		\hline
-		\hline
-		$MR$ & Master Reset \\
-		\hline
-		$\lnot WR$  & Write Not\\
-		\hline
-		$\lnot RD$  & Read Not \\
-		\hline
-		$\lnot MS1$ & Module Select 1 Not \\
-		\hline
-		$\lnot MS2$ & Module Select2 Not\\
-		\hline
-	\end{tabular}
-	\caption{Signals on the control bus}
-	\label{tab:ctrl_bus}
-\end{table}
+\begin{itemize}
+	\item{$MR$ ... Master Reset}
+	\item{$\lnot WR$ ... Write Not}
+	\item{$\lnot RD$ ... Read Not}
+	\item{$\lnot MS1$ ... Module Select 1 Not}
+	\item{$\lnot MS2$ ... Module Select 2 Not}
+\end{itemize}
 
-
-\paragraph{Master Reset}
+\subsubsection{Master Reset}
 
 A high level on the $MR$ lane signals to the peripherials that a reset of all
 registers and states should occure. This is needed for the serial console and
 the DAC.
 
-\paragraph{Write Not}
+\subsubsection{Write Not}
 A low level on the $\lnot WR$ lane signals the corresponding modules that the 
 data on
 the data bus should be written to the register on the address specified from the
 address bus.
 
-\paragraph{Read Not}
+\subsubsection{Read Not}
 A low level on the $\lnot RD$ lane signals the corresponding modules that the 
 data
 from the register specified by the address on the address bus should be written
 to the data bus.
 
-\paragraph{Module Select 1 and 2 Not}
+\subsubsection{Module Select 1 and 2 Not}
 
 A low level on one of these lines signals the corresponding module that the
 data on address data and the control lines is meant for it.
 
-\paragraph{Sepearation of $\lnot RD$/$\lnot WR$ and$\lnot MS1$/$\lnot MS2$}
-
-The Read Not and Write Not lines could be combined into one line $\lnot RD/WR$.
-The same can be done for the Module Select lanes. In both cases this would
-have made wiring inside the finished modules more difficult and if both were
-combined the bus would not be able to not perform an action at any given
-point in time. Therefore these signals have not been combined.
-
 \subsection{Von Neumann Archtiecture}
 
 The term ``von Neumann architecture`` referrs to a type of computer architecture

sections/DP/UART/main.tex

@@ -22,7 +22,7 @@ more common interface.
 
 The 16550 UART is in it's core a 16450 UART, but has been given a FIFO
 \footnote{First-In First-Out} buffer. It needs three address lines, and 8
-data lines, which can be seen in Figure \ref{fig:16550_pinout}
+data lines, which can be seen in figure \ref{fig:16550_pinout}
 
 \begin{figure}[H]
 	\centering
@@ -31,7 +31,7 @@ data lines, which can be seen in Figure \ref{fig:16550_pinout}
 	\label{fig:16550_pinout}
 \end{figure}
 
-In Figure \ref{fig:16550_pinout} the most important lanes are the SIN and
+In figure \ref{fig:16550_pinout} the most important lanes are the SIN and
 SOUT lanes, as they contain the serial data to and from the 16550 UART.
 
 \subsubsection{MAX-232}
@@ -60,13 +60,13 @@ ozillator from which all common baud rates can still be derived
 \cite{pc16550}.
 Resistors R1 and R2 are for stability and functionality of the Oszillator
 nescessary as per datasheet. The resulting frequency can be measured via
-J1 as can be seen in Figure \ref{fig:uartquartz}. C1 is used to 
+J1 as can be seen in figure \ref{fig:uartquartz}. C1 is used to 
 stabilize the
 voltage for the 16550 UART and is common practice. Via JP1 the UART can be
 transformed into a USRT, where the receiver is synchronized to the transmitter
 via a clock line. This mode has, however, not been tested, and the clock needs
 to be 16 times the receiver clock rate\cite{pc16550}. The final output of the
-16550 UART can be used and measured via J2, as shown in Figure \ref{fig:uart232}
+16550 UART can be used and measured via J2, as shown in figure \ref{fig:uart232}
 . Before the UART on J2 can be used however, the Jumpers JP2 and JP3 need to be
 removed, as otherwise the MAX-232 will short out with the incoming signal.
 Capacitors C4, C6, C7 and C8 are for the voltage pump as defined in the
@@ -74,7 +74,7 @@ datasheet\cite{max232}. R4 and R5 have been suggested by the supervisor in
 order to avoid damage to the MAX-232. The RJ-45 plug is used to transmit the
 TIA-/EIA-232 signal, rather than the more common D-SUB connector, because the
 RJ-45 connector fits on a 2.54mm grid. The Pinout of the RJ-45 plug can be seen
-in Figure \ref{fig:rs232rj45}. C5 has the same functionality for the
+in figure \ref{fig:rs232rj45}. C5 has the same functionality for the
 MAX-232 as the C1 has to the 16550-UART.
 
 \begin{figure}[H]
@@ -93,6 +93,7 @@ MAX-232 as the C1 has to the 16550-UART.
 	\caption{Measurement of the 1.8432 MHz Output on J1}
 	\label{fig:uartquartz}
 \end{figure}
+
 \begin{figure}[H]
 \begin{tikzpicture}
 	\begin{axis}[
@@ -125,8 +126,8 @@ To demonstrate the functionality and prove that the schematic has no underlying
 error, a program which regularly transmits a character was written as well as
 a simple echo program, which transmits all received characters. Both programs
 transmit 8 bit characters without parity at 38400 Baud. The output for program
-one can be seen in Figure \ref{fig:uart232} and the output for program two in
-Figure \ref{fig:232_echo}. 
+one can be seen in figure \ref{fig:uart232} and the output for program two in
+figure \ref{fig:232_echo}. 
 
 \begin{figure}[H]
 \begin{tikzpicture}
@@ -150,7 +151,7 @@ Figure \ref{fig:232_echo}.
 \paragraph{Transmit code}
 The transmit code regularly transmits the letter capital A  via the 16550 UART.
 Before it can do this it needs to perform some initialisations. The
-functions shown in Listing \ref{lst:16550-general} are the read and write
+functions shown in listing \ref{lst:16550-general} are the read and write
 routines for accessing the 16550 UART. These routines also apply to the echo
 code. 
 \lstinputlisting[language=C,frame=trBL,
@@ -166,7 +167,7 @@ baud rate, and the character width and parity control
 needs to be set. The $MR$ signal is beeing generated by the AVR on bootup. To
 access the divisor latch, the divisor latch access bit needs to be set and
 after setting up the baud rate divisor latch, it nees to be cleared to allow
-a regular transmission. This process can be seen in Listing \ref{lst:16550-transmit}
+a regular transmission. This process can be seen in listing \ref{lst:16550-transmit}
 \lstinputlisting[language=C,frame=trBL,
 	breaklines=true, breakautoindent=true, formfeed=\newpage,
 	label={lst:16550-transmit}, caption={16550 INIT routines and single char transmission},
@@ -174,7 +175,7 @@ a regular transmission. This process can be seen in Listing \ref{lst:16550-trans
 		{code/16550/transmit/src/main.c}
 
 The output of this code on the address, data and control bus as well as on the
-SOUT lane of the 16550 UART can be seen in Figure \ref{fig:16550A}
+SOUT lane of the 16550 UART can be seen in figure  \ref{fig:16550A}
 
 \begin{figure}[H]
 	\centering
@@ -187,9 +188,9 @@ SOUT lane of the 16550 UART can be seen in Figure \ref{fig:16550A}
 
 The echo code permanently polls the 16550 UART wether a character has been
 received, and if yes, reads it from the receiver holding register and writes it
-back to the tx holding register. The output of this code can be seen in Figure
+back to the tx holding register. The output of this code can be seen in figure
 \ref{fig:232_echo}. The initialisation is practically the same as for the
-transmission code, as well as the read and write routines in Listing 
+transmission code, as well as the read and write routines in listing 
 \ref{lst:16550-general}.
 
 \lstinputlisting[language=C,frame=trBL,
@@ -200,7 +201,7 @@ transmission code, as well as the read and write routines in Listing
 
 \subsubsection{Final Module}
 
-The final module can be seen in Figure \ref{fig:16550_mod} with the pc16550 UART
+The final module can be seen in figure \ref{fig:16550_mod} with the pc16550 UART
 in the center and the MAX-232 above. 
 
 \begin{figure}[H]

sections/DP/dac/main.tex

@@ -17,7 +17,7 @@ dual R2R Ladder dac which takes \textbf{PARALLEL} input, which is an important
 feature, because the backbone of the project is its parallel bus. Further the
 DAC was developed for audio aplications\cite{tlc7528} which made its use obvious
 and the TLC-7528 was the only IC available as DIP
-\footnote{DIP... Dual Inline Package}, of which the pinout can be seen in Figure
+\footnote{DIP... Dual Inline Package}, of which the pinout can be seen in figure
 \ref{fig:tlc7528_pinout}
 
 \begin{figure}[H]
@@ -31,7 +31,7 @@ and the TLC-7528 was the only IC available as DIP
 
 The IDT7201 is an asychronous CMOS FIFO, which means that it can be read with
 a completely independant speed from which it is written and vice versa. It has
-9 bit words, which can be seen in Figure \ref{fig:idt7201_pinout}, and can 
+9 bit words, which can be seen in figure \ref{fig:idt7201_pinout}, and can 
 store up to 256 words\cite{idt7201}. It is used as a buffer
 to store data describing the targeted waveform in order to free time on the
 parallel bus for interaction with the 16550 UART. 
@@ -49,9 +49,9 @@ Before tests of the complete unit were conducted, the functionality of the
 device and the validity of the knowledge of operations were performed. For that
 the DAC was directly connected to the ATMega without the FIFO in front of it.
 A saw was generated on only the DACA channel, which was put into voltage mode
-as described in the datasheet\cite{tlc7528} and seen in Figure 
+as described in the datasheet\cite{tlc7528} and seen in figure 
 \ref{fig:tlc7528_volt}. 
-After the result seen in Figure \ref{fig:tlc7528_saw_nonlin}
+After the result seen in figure \ref{fig:tlc7528_saw_nonlin}
 was measured, a lot of effort was put in to determine the source of the heavy
 noise, however no obvious conclusions can be made, execpt that it comes from the
 DAC itself and is consistant over whatever frequency used. A damaged IC could be
@@ -129,7 +129,7 @@ DAC, which makes the data available on the output before being stored into the
 DAC as it receives the signal to store the data after the FIFO makes it
 available on the bus.
 
-The DAC is operated in voltage mode, as described in Figure \ref{fig:tlc7528_volt},
+The DAC is operated in voltage mode as described in \ref{fig:tlc7528_volt},
 with it's voltage source beeing available at either $3.472V_{pp}$ for 
 professional
 audio or $0.894V_{pp}$ for consumer audio, as defined per convention.\cite{audiob}
@@ -148,32 +148,6 @@ filtered away.
 R7 and R8 have been installed in order to unload the capacitors after device
 poweroff.
 
-\paragraph{Functional Description}
-
-On a read of the module the $\lnot MS2$ line goes low as well as the $\lnot RD$
-line, which combined by the as OR gate used diodes D1/D2 and resistor R1 forms 
-the MODREAD
-signal. The modread signal is passed on to the $\lnot OE$ pin of the D-Flip-Flop
-which writes the FIFO status bits onto the data bus.
-
-On write the same or gate is formed with diodes D3/D4 and resistor R2 which
-combines signals $\lnot MS2$ and $\lnot WR$ into MODWRITE. MODWRITE is then fed
-into the $\lnot W$ pin of the FIFO which stores the data on the data bus into
-it's internal buffer.
-
-The FIFO is read with the clock generated by the NE555
-(see the NE555 paragraph below) which puts the data onto the bus between FIFO
-and DAC. The DAC reads the data into its internal buffer after the FIFO has put
-it onto the DATA lanes due to the inversion by the B part of the 74HC00 and the
-output beeing mapped to the $\lnot CS$ pin of the DAC. When
-the FIFO is empty it produces nonsense as output, to mittigate errors resulting
-from this the $\lnot EF$ output of the FIFO is inverted by the C part of the
-74HC00 and put onto the $\lnot WR$ pin of the DAC.
-
-The maximum amplitude can be selected by jumper JP1. Generated waveforms by the
-DAC are filtered against a DC offset via the highpasses built by C5/R7 and C6/R8
-respectively. The resulting waveform can be measured on audio jack J1.
-
 \paragraph{NE55 Clock Source}
 
 Though used as a clock source, the NE555 is a bad clock source, if a stable
@@ -188,35 +162,15 @@ via conventional electronic resellers.
 
 \subsubsection{DAC Module Read}
 
-On a read the status bits of the FIFO, which has been latched into the 74HC374
-D-Flip-Flop, are written onto the Data bus. Table \ref{tab:dac_data} defines the
-layout of these status bits on the data bus.
+On a read the status bits of the FIFO, which have been latched into the 74HC374
+D-Flip-Flop, are written onto the Data bus. Table \ref{tab:dac_data}
 
 \begin{table}[H]
 	\centering
-	\begin{tabular}{| c | r |}
-		\hline
-		\textbf{Bit position} & \textbf{Usage}\\
-		\hline
-		\hline
-		0 & FIFO empty flag \\
-		\hline
-		1 & Not used (originally FIFO low)\\
-		\hline
-		2 & FIFO half full\\
-		\hline
-		3 & FIFO full \\
-		\hline
-		4 & Not used\\
-		\hline
-		5 & Not used\\
-		\hline
-		6 & Not used\\
-		\hline
-		7 & Not used\\
-		\hline
+	\begin{tabular}{ c | r |}
+		
 	\end{tabular}
-	\caption{The layout of the Data Bus on DAC read}
+	\caption{The layout of the Data Bus on read}
 	\label{tab:dac_data}
 \end{table}
 

sections/DP/plan.tex

@@ -1,162 +0,0 @@
-\subsection{Hardware peripherials}
-
-Planning of the peripherials was done based on the information provided on large
-parts by David Oberhollenzer. A lot of his advice contributed heavily to the
-direction the development went. 
-
-\subsubsection{Peripherial selection}
-
-The selection of the hardware peripherials was done based on implementation
-difficulty, common use in computer systems, relevance in current times and
-wether they were fitting for demonstrative purposes.
-
-\paragraph{Serial communication interface}
-
-Serial communication interfaces have been around for a long time. They have been
-used for many different applications from early mouse pointer devices
-\cite{232mouse} to user input terminals\cite{vt100}
-which are far away from the real computer system. They are still very common in
-smaller embedded sytems and in the server space where they are used as a simple
-and less error prone way to interface with the operating system and programs
-running there. They are fairly easy to implement as there are a  interface
-ICs which provide a more generic interface for serial communications
-\cite{pc16550}. Most SOCs
-\footnote{SOC... System on a Chip} have some form of serial communication
-interface. The most common serial interface voltages are 3.3V, 5V and levels
-as per TIA-/EIA-232 specification\cite{rs232}.
-
-\paragraph{Parallel Port interface}
-
-Parallel ports are absent on most modern computer systems but historically have
-been the high speed interfaces on computers. Early computer systems used 
-parallel-ports for expansions and the ISA-Bus
-\footnote{ISA...Industry Standard Architecture} was for some time the main way
-of expansion for PCs
-\footnote{PC in this thesis referrs to Computer Systems using the x86 
-Architecture}. Most younger people remeber parallel ports as the port for
-printers on their home PCs. A prallel port is easy to implement because it has
-simmilar use of control, data and address lines like a processor uses internally
-anyways\cite{laval_parallel}. Usage of the standard IEEE 1284 port limits the
-design to the signals on this port or makes the use of the signals on this port
-obligatory.
-
-\paragraph{Digital to Analog Converter}
-
-Digital to Analog Converters or more commonly DACs are used on all modern PCs
-for sound output. They have been around for longer and some external sound card
-interfaces have been standardisedlike AC '97\cite{ac97}. Implementation of a
-standard audio interface requires higher speed connections or more precise 
-timing for ac97 for example. Earlier computer systems did not have a sound card
-as it doesn't have import usage for computing and user input tasks and later
-on computer systems only had a PC speaker for diagnostics such as the IBM PC AT
-\cite{ibmpc} which can only procude one specific frequency and does not have a
-DAC. A dac is not easy to implement as it requires a constant sampling rate and
-a buffer to be of any practical use.
-
-\paragraph{Graphical output / GPU}
-
-Graphical output on older computer systems such as the EDVAC
-\cite{neumann} was not possible because it requires
-either a heavy load on the processor or dedicated hardware and due to the mostly
-scientific use it was easier to just print the caracters as letters via a
-printer. Drawing characters
-onto a screen is by itself not an easy task as it requires, for example for
-VGA a Digital to Analog Converter with 25MHz sampling rate and a buffer to
-contain all needed data for one frame or at least parts of it, while the CPU
-renders the frame\cite{vga}. Screen output is one of the if not the most common
-form of output on a computer today.
-
-\paragraph{Inter Integrated Circuit}
-
-Inter Integrated Circuit or IIC for short is a standard for serial transmission
-between Integrated circuits\cite{iic}. This is done on a master-slave basis and
-transmission speed is fairly low in standard 100kBit/s mode. The bus is used
-on many different platforms for many different things including HDMI DDC
-\cite{ddc}. Though there are some IIC ICs which can interface with a parallel
-bus such as the PCA9564 \cite{pca9564} but these are either limited in
-capability or not easy to use and implement. Most people don't have an
-understanding of IIC as it is only known in technical fields.
-
-\paragraph{Utility analysis}
-
-Among the above mentioned processor peripherials from the criteria mentioned
-before a utility analysis was performed. To do this different point have been
-credited for the criteria mentioned which can be seen in Table 
-\ref{tab:utility_base}. The multipliers in Table \ref{tab:utility_base} have
-been applied to the points and the sums in Table \ref{tab:utility_result} 
-resulted. Based on this 
-result the DAC and Serial Communication interface were chosen as peripherials.
-
-\begin{table}[H]
-	\centering
-	\resizebox{\textwidth}{!}{
-		\begin{tabular}{ |l||c|c|c|c|c|}
-			\hline
-			Criteria 	& serial port   & parallel port & DAC	& GPU	& IIC\\
-			\hline
-			\hline
-			implementation	& 0		& 0		& 1	& 4	& 2\\
-			\hline
-			common use	& 2		& 1		& 3	& 3	& 1\\
-			\hline
-			relevance	& 2		& 1		& 3	& 3	& 1\\
-			\hline
-			demonstrative	& 2		& 1		& 3	& 2	& 1\\
-			\hline
-
-		\end{tabular}
-	}
-	\caption{utility analysis base points for peripherials}
-	\label{tab:utility_base}
-\end{table}
-
-\begin{table}[H]
-	\centering
-	\begin{tabular}{ |l|c|}
-		\hline
-		Criteria 	& multiplier \\
-		\hline
-		\hline
-		implementation &	-2\\
-		\hline
-		common use &		1\\
-		\hline
-		relevance &		2\\
-		\hline
-		demonstrative &		3\\
-		\hline
-
-
-	\end{tabular}
-	\caption{utility analysis multipliers for peripherials}
-	\label{tab:utility_mul}
-\end{table}
-
-
-\begin{table}[H]
-	\centering
-	\resizebox{\textwidth}{!}{
-		\begin{tabular}{ |l||c|c|c|c|c|}
-			\hline
-			Criteria 	& serial port   & parallel port & DAC	& GPU	& IIC\\
-			\hline
-			\hline
-			implementation	& 0	& 0	& -2	& -8	& -4\\
-			\hline
-			common use	& 2	& 1	& 3	& 3	& 1\\
-			\hline
-			relevance	& 4	& 2	& 6	& 6	& 2\\
-			\hline
-			demonstrative	& 6	& 3	& 9	& 6	& 3\\
-			\hline
-			\hline
-			\textbf{SUM}	& 12	& 6	& 16	& 7	& 2\\
-			\hline
-
-			\hline
-
-		\end{tabular}
-	}
-	\caption{utility analysis results for peripherials}
-	\label{tab:utility_result}
-\end{table}

sections/abstract.tex

@@ -10,9 +10,8 @@ implementiert sowie diverse Parallelbus gebundene Hardwareperipherie entwickelt
 und gebaut. Als Harwareperipherie wurde ein 8-Bit 2-Kanal DAC und eine serielle
 Schnittstelle mit TIA-/EIA-232 Pegeln gewählt. Der Prozessor implementiert das
 RISC-V32I base instruction set. Aufgrund der starken Verwendung von Englisch im
-Software- und Hardwarebereich wurde diese Diplomarbeit in Englisch verfasst, 
-wodurch
-ebenfalls die Lesbarkeit erhöht wird. Die entstandene Dokumentation soll für
+Software- und Hardwarebereich wurde diese Diplomarbeit in Englisch verfasst, was
+ebenfalls die Lesbarkeit erhöhen soll. Die entstandene Dokumentation soll für
 Menschen mit einem grundlegenden Verständnis von Elektronik sowie der Hardware-
 Beschreibungssprache VHDL verständlich sein.
 \end{otherlanguage}
@@ -24,7 +23,7 @@ this goal a RISC-V32I processor has been implemented in VHDL on a XILINX FPGA
 as well as some peripherials bound to the parallel bus. These peripherials
 include a 2-channel 8-bit Digital to analog converter as well as a TIA-/EIA-232
 compliant serial interface. Due to the common use of english in the hardware and
-software engineering field this thesis is written in english, which
-enhances readability as well. The written documentation should be comprehensible
+software engineering field this thesis was written in english, which should
+enhance readability as well. The written documentation should be understandable
 for everyone with a basic understanding of electronics as well as the
 hardware description language VHDL.

sections/intro.tex

@@ -1,22 +0,0 @@
-In early 2018, more than a year before the official start of the project, after
-searching for a subject for the diploma thesis, the idea of building a computer
-from scratch has come up. Multiple suggestions on how to implement it and the
-scope of the project were gathered. Originally the goal of the project was to
-have a computer which would consist of seperate plug-in cards on each of which
-one instruction would reside. This would debunk the mystery behind the ``black
-box`` which processors today are.
-
-Most processors today are only documented on the execution of their programs and
-not on their internals. The projects aim was later redirected, due to concerns
-about the difficulty of the project, to build a processor in VHDL instead. After
-several months of implementation time the project was split into two parts: the
-peripherials and the core processor. During the development processes and after
-rememberingthe original goal to make a processor understandable, the
-peripherials changed from being implemented in VHDL back to hardware, which came
-with increased work but would result in a far more understandable final product.
-
-The decision for a RISC-V based processor was made at the beginning of the 
-project, because the core architecture is well documented, modular and almost
-any part not implemented inside the processor(if not specifically
-required by the software) should be emulateable in software.
-

sections/result.tex

@@ -1,13 +1,12 @@
-The project is fully implemented with all functionality originally targeted.
-The system has been tested and verified. All example codes have been
-documented and tested. Hardware implementations were created using
-open-source programs, while the RISC-V processor can be compiled with an open 
-source
+The project was fully implemented with all functionality originally targeted.
+The system has been tested and verified and all example code have been
+documented and tested as running. Implementations in hardware were made in
+open-source programs and the RISC-V processor can compile using an open source
 toolchain. The completed project can be found on the USB stick which accompanies
 this thesis, or in the git repositories at 
 \url{https://git.it-syndikat.org/tyrolyean/dipl.git} and 
 \url{https://gitlab.com/YARM-project/}. The completed hardware peripherials can
-be seen in Figure \ref{fig:all_mod}
+be seen in figure \ref{fig:all_mod}
 
 \begin{figure}[H]
 	\centering