MOAR STUFF
Signed-off-by: Tyrolyean <tyrolyean@tyrolyean.net>
This commit is contained in:
parent
05617c9370
commit
6c6323b3cc
20 changed files with 111796 additions and 59 deletions
|
@ -34,6 +34,7 @@
|
|||
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},
|
||||
|
@ -158,3 +159,67 @@
|
|||
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}
|
||||
}
|
||||
|
|
111354
documents/mst1/1502494_PC_AT_Technical_Reference_Mar84.pdf
Normal file
111354
documents/mst1/1502494_PC_AT_Technical_Reference_Mar84.pdf
Normal file
File diff suppressed because one or more lines are too long
BIN
documents/mst1/AC97_OVR.PDF
Normal file
BIN
documents/mst1/AC97_OVR.PDF
Normal file
Binary file not shown.
BIN
documents/mst1/Intel_ISA_Spec2.01_Sep89.pdf
Normal file
BIN
documents/mst1/Intel_ISA_Spec2.01_Sep89.pdf
Normal file
Binary file not shown.
BIN
documents/mst1/Serial Mouse Detection.pdf
Normal file
BIN
documents/mst1/Serial Mouse Detection.pdf
Normal file
Binary file not shown.
BIN
documents/mst1/UM10204.pdf
Normal file
BIN
documents/mst1/UM10204.pdf
Normal file
Binary file not shown.
BIN
documents/mst1/VESA-EDDC-1.2.pdf
Normal file
BIN
documents/mst1/VESA-EDDC-1.2.pdf
Normal file
Binary file not shown.
BIN
main.pdf
(Stored with Git LFS)
BIN
main.pdf
(Stored with Git LFS)
Binary file not shown.
19
main.tex
19
main.tex
|
@ -115,14 +115,14 @@ geschlechtsunabh"angig verstanden werden soll.
|
|||
\setcounter{section}{0}
|
||||
\pagenumbering{arabic}
|
||||
|
||||
%\section{Einleitung}
|
||||
%\input{sections/einleitung.tex} TODO
|
||||
\section{Introduction}
|
||||
\input{sections/intro.tex}
|
||||
|
||||
\section{Task description}
|
||||
\DP\input{planung/DP/aufgabenstellung.tex}
|
||||
|
||||
%\section{Planung}
|
||||
%\DP\input{planung/DP/planung.tex}
|
||||
\section{Organization}
|
||||
\DP\input{sections/DP/plan.tex}
|
||||
|
||||
\clearpage
|
||||
\pagestyle{fancy}
|
||||
|
@ -203,11 +203,12 @@ geschlechtsunabh"angig verstanden werden soll.
|
|||
%\input{sections/Anhang/Pflichtenheft/pflichtenheftMR.tex}
|
||||
%
|
||||
%\newpage
|
||||
%\subsection{Schlussfolgerung / Projekterfahrung}
|
||||
%\input{sections/Anhang/schlussfolgerung.tex}
|
||||
|
||||
%\subsection{Projektterminplanung}
|
||||
%\MR\input{sections/Anhang/Projektterminplanung/projektterminplanungMR.tex}
|
||||
\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}
|
||||
|
||||
\clearpage
|
||||
%\subsection{Arbeitsnachweis Diplomarbeit}
|
||||
|
|
|
@ -0,0 +1,54 @@
|
|||
\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}
|
||||
|
0
sections/Anhang/planung.tex
Normal file
0
sections/Anhang/planung.tex
Normal file
8
sections/Anhang/schlussfolgerung.tex
Normal file
8
sections/Anhang/schlussfolgerung.tex
Normal file
|
@ -0,0 +1,8 @@
|
|||
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.
|
|
@ -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.
|
||||
|
|
|
@ -52,50 +52,73 @@ 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.
|
||||
|
||||
\subsection{Data Bus}
|
||||
\subsubsection{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.
|
||||
|
||||
\subsection{Control Bus}
|
||||
\subsubsection{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{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}
|
||||
\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}
|
||||
|
||||
\subsubsection{Master Reset}
|
||||
|
||||
\paragraph{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.
|
||||
|
||||
\subsubsection{Write Not}
|
||||
\paragraph{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.
|
||||
|
||||
\subsubsection{Read Not}
|
||||
\paragraph{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.
|
||||
|
||||
\subsubsection{Module Select 1 and 2 Not}
|
||||
\paragraph{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
|
||||
|
|
|
@ -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]
|
||||
|
@ -125,8 +125,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 +150,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 +166,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 +174,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 +187,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 +200,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]
|
||||
|
|
|
@ -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 \ref{fig:tlc7528_volt},
|
||||
The DAC is operated in voltage mode, as described in Figure \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,6 +148,32 @@ 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
|
||||
|
@ -162,15 +188,35 @@ via conventional electronic resellers.
|
|||
|
||||
\subsubsection{DAC Module Read}
|
||||
|
||||
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}
|
||||
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.
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
\begin{tabular}{ c | r |}
|
||||
|
||||
\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
|
||||
\end{tabular}
|
||||
\caption{The layout of the Data Bus on read}
|
||||
\caption{The layout of the Data Bus on DAC read}
|
||||
\label{tab:dac_data}
|
||||
\end{table}
|
||||
|
||||
|
|
162
sections/DP/plan.tex
Normal file
162
sections/DP/plan.tex
Normal file
|
@ -0,0 +1,162 @@
|
|||
\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}
|
|
@ -10,8 +10,9 @@ 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, was
|
||||
ebenfalls die Lesbarkeit erhöhen soll. Die entstandene Dokumentation soll für
|
||||
Software- und Hardwarebereich wurde diese Diplomarbeit in Englisch verfasst,
|
||||
wodurch
|
||||
ebenfalls die Lesbarkeit erhöht wird. Die entstandene Dokumentation soll für
|
||||
Menschen mit einem grundlegenden Verständnis von Elektronik sowie der Hardware-
|
||||
Beschreibungssprache VHDL verständlich sein.
|
||||
\end{otherlanguage}
|
||||
|
@ -23,7 +24,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 was written in english, which should
|
||||
enhance readability as well. The written documentation should be understandable
|
||||
software engineering field this thesis is written in english, which
|
||||
enhances readability as well. The written documentation should be comprehensible
|
||||
for everyone with a basic understanding of electronics as well as the
|
||||
hardware description language VHDL.
|
||||
|
|
22
sections/intro.tex
Normal file
22
sections/intro.tex
Normal file
|
@ -0,0 +1,22 @@
|
|||
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.
|
||||
|
|
@ -1,12 +1,13 @@
|
|||
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
|
||||
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
|
||||
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
|
||||
|
|
Loading…
Reference in a new issue