\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 Stages. Jene sind Fetch, Decode, Execute und Writeback.
+
+Die Pipeline gliedert sich in 4 getrennte Stufen, diese sind Fetch, Decode, Execute und Writeback. Die Aufgaben der jeweiligen Stufen
+werden in den folgenden Abschnitten beschrieben.
+
+
\section{Fetch-Stage}
-Die Aufgaben der Fetch-Stage sind relativ simple in
+Die Aufgaben der Fetch-Stage sind relativ einfach.
\begin{itemize}
\item Anlegen der Instruktionsadresse an den Instruktions-Speicherbus. Daraufhin erh\"alt die Decode-Stage die gew\"unschte Instruktion im n\"achsten Zyklus.
- \item Die Instruktionsadresse ist entweder der inkrementierte Programmcounter, Jump-Result oder das Ergebnis der statischen Branchprediction
+ \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
+
+Die Aufgaben der Decode-Stage fallen schon etwas komplexer aus:
\begin{itemize}
\item Decodieren der dichten Instruktion in eine aufgespaltene Form.
- \item Laden der Operanden aus dem Registerfile und \"ubergeben der jeweiligen Adressen.
- \item Laden von Immediates in die Operanden.
- \item Evaluierung der Branchprediction. R\"uckf\"uhrung der statischen Sprungadresse
- und NOP insertion falls die ALU/Writeback springt.
+ \item Anlegen der Adressen der in der Instruktion verwendeten Operandenregister an den Speicherbus des Registerfiles, dessen Inhalt liegt im Folgezyklus der ALU vor.
+ \item Im Falle von Immediate-Operationen wird der Immediatewert in das Nachfolgepipelineregister geschrieben, somit kann dieser von der ALU im Folgezyklus verwendet werden.
+ \item In der Instruktion ist eine statische Branch-prediction codiert. Die Fetch-Stage f\"urt also im Falle eines m\"oglichen Immediate-Sprunges die Sprungadresse an die Fetch-Stage zur\"uck.
+ \item Decode implementiert beim R\"uckschreiben in das Registerfile ''Read through Write'', somit erleichtert dies die Forwardunit der Exec-Stage.
+
+%Evaluierung der Branchprediction. R\"uckf\"uhrung der statischen Sprungadresse
+% und NOP insertion falls die ALU/Writeback springt.
+
+
\end{itemize}
-gegliedert.
+
+
\section{Execute-Stage}
-Neben den Berechnungen beinhaltet diese Stage auch die Forward-Unit welche s\"amtlichen
-Konflikte behandelt.
+
+Neben den Berechnungen beinhaltet diese Stufe auch die Forward-Unit welche Datenabh\"angigkeiten zusammen mit der Decodestage aufl\"ost.
+
\begin{itemize}
- \item Ausf\"uhrung der einzelnen Instruktionen auf die Operanden
- \item Signalisieren eines Sprungs (ret vs. jmp). Die Jumpadresse kommt entweder vom Datenbus oder aus dem ALU-Ergebnis.
- \item Signalisieren eines Registerschreibzugriffs, wobei dieses Ergebnis wieder vom Result oder Datenbus kommt.
+ \item Ausf\"uhrung der arithmetischen und logischen Berechnungen
+ \item Signalisieren eines Sprungs (ret vs. jmp). Jumpadresse kommt entweder vom Datenbus des Speichers (Stack) oder aus dem ALU-Ergebnis.
+ \item Setzen von Write-Enable der R\"uckschreibeinheit in Abh\"angigkeit der Predicate Bits und des Statusworts.
\item Ansprechen des Datenbusses (RAM, Extension-Module, read, write) und des Statuswortes sowie des Stackpointers.
\end{itemize}
-Die Forward-Unit muss s\"amtliche 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 Forward-Unit muss s\"amtliche 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}
+
+Da die Decode-Stage bereits eine Lese/Schreiblatenz von einem Zyklus auf das Registerfile abdeckt muss sich die Forward Unit der Execute Stage noch das Ergebnis
+der letzten Operation merken um s\"amtliche Datenabh\"angigkeiten aufzul\"osen (Beispiel anhand folgender Instruktionen: r0 = 1; r1 = 2; r2 = r0 + r1).
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 \"uber ein Register auf das Modul weiter.
\section{Writeback-Stage}
-Die Writeback-Stage \"ubernimmt die Werte aus dem Ergebnisregister der ALU oder aus der Forward-Unit (Registerzusammensetzung) und schreibt diese in das Registerfile zur\"uck.
-Des weiteren kann die ALU das Jump Result nicht direkt an die Decode-Stage zur\"uckgeben, da dieses erst im Folgezyklus vorhanden ist (im Falle eines branch-returns).
-Somit muss dies auch von der Writeback-Stage erledigt werden.
+Die Writeback stage \"ubernimmt die Werte aus dem Ergebnisregister der Alu und schreibt diese in das Registerfile zur\"uck.
+Des weiteren kann die ALU das Jump Result nicht direkt an die Decode Stage zur\"uckgeben, da dieses erst im Folgezyklus vorhanden ist (im Falle eines branch-returns).
+Somit muss dies auch von der Writeback Stage abgedeckt werden.
+
projects / calu.git / commitdiff