X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=4_block%2Fblockdesc.tex;fp=4_block%2Fblockdesc.tex;h=342a95d948b8cfd02a87dbed71ea9a9db05293a3;hb=2c4b25bb70af1903e6133469d13bbc8080214405;hp=0000000000000000000000000000000000000000;hpb=cb84d3f70eb8e305ceff331b08999f8df4550111;p=calu.git

diff --git a/4_block/blockdesc.tex b/4_block/blockdesc.tex
new file mode 100644
index 0000000..342a95d
--- /dev/null
+++ b/4_block/blockdesc.tex
@@ -0,0 +1,48 @@
+\section{Allgemein}
+%\abbildung{pipeline.png}{so schaut unsre Architektur aus}{fig:pipeline}{1.4\textwidth}{90}
+\abbildung{pipeline.png}{Schematische Darstellung der Pipeline}{fig:pipeline}{0.95\textheight}{90} %0.95 weil sonst warning!
+Die Pipeline gliedert sich in 4 getrennte Stufen. Jene sind Fetch, Decode, Execute und Writeback.
+\section{Fetch-Stage}
+Die Aufgaben der Fetch-Stage sind relativ simple in
+\begin{itemize}
+	\item Anlegen der Instruktionsadresse an den Instruktions-Speicherbus. Daraufhin erhält die Decode-Stage die gewünschte Instruktion im nächsten Zyklus.
+	\item Die Instruktionsadresse ist entweder der inkrementierte Programmcounter, Jump-Result oder das Ergebnis der statischen Branchprediction
+\end{itemize}
+gegliedert.
+\section{Decode-Stage}
+Die Aufgaben der Decode-Stage fallen schon etwas komplexer aus und sind in
+\begin{itemize}
+	\item Decodieren der dichten Instruktion in eine aufgespaltene Form.
+	\item Laden der Operanden aus dem Registerfile und übergeben der jeweiligen Adressen.
+	\item Laden von Immediates in die Operanden.
+	\item	Evaluierung der Branchprediction. Rückführung der statischen Sprungadresse
+				und NOP insertion falls die ALU/Writeback springt.
+\end{itemize}
+gegliedert.
+\section{Execute-Stage}
+Neben den Berechnungen beinhaltet diese Stufe auch die Forward-Unit welche s\"amtlichen
+Konflikte behandelt.
+\begin{itemize}
+	\item Ausführung der einzelnen Instruktionen auf die Operanden
+	\item Signalisieren eines Sprungs (ret vs. jmp). Jumpadresse kommt entweder vom Datenbus oder aus dem ALU-Ergebnis.
+	\item Signalisieren eines Registerschreibzugriffs, wobei dieses Ergebnis wieder vom Result oder Datenbus kommt.
+	\item	Ansprechen des Datenbusses (RAM, Extension-Module, read, write) und des Statuswortes sowie des Stackpointers.
+\end{itemize}
+
+
+Die Forward-Unit muss sämtliche Konflikte behandeln und veraltete Operanden durch die letzten Ergebnisse ersetzen. Sie besteht aus
+\begin{itemize}
+	\item 2-Register um \"Anderungskonflikte an Registern zu l\"osen.
+	\item	Zusammensetzen eines dieser zwei Register mit dem Wert vom Datenbus (load byte etc.).
+\end{itemize}
+
+Die Extensionmodule werden vom Prozessor aus wie der Speicher behandelt. Jedes Modul besitzt einen spezifischen Adressbereich.
+Ein eigener Controller mapped die Adressbereiche auf die Extensionmodule und leitet die entsprechenden Daten über ein Register auf das Modul weiter. 
+Beim Lesezugriff auf einen dieser Speicherbereiche legt das Extensionmodul einen Zyklus sp\"ater seinen Output auf den Datenbus. 
+
+
+\section{Writeback-Stage}
+
+Die Writeback stage übernimmt die Werte aus dem Ergebnisregister der Alu oder aus der Forwardunit(Registerzusammensetzung) und schreibt diese in das Registerfile zurück. 
+Des weiteren kann die ALU das Jump Result nicht direkt an die Decode stage zurückgeben, da dieses erst im Folgezyklus vorhanden ist (im Falle eines branch-returns).
+Somit muss dies auch von der Writeback Stage erledigt werden.
\ No newline at end of file