[Speicher] Ergänze Inhalte Decoder/Multiplexer

This commit is contained in:
Andre Meyering 2017-12-04 12:35:19 +01:00
parent a85900c418
commit 01ffd023fa
Signed by: Andre
GPG key ID: 5A1BBB0FB1D4716B
7 changed files with 170 additions and 2 deletions

BIN
Bilder/4_16_Dekoder.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.9 KiB

BIN
Bilder/HS_Kondensator.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.5 KiB

BIN
Bilder/Matrix_Decoder.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

BIN
Bilder/Schaltnetz_MUX.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 56 KiB

After

Width:  |  Height:  |  Size: 59 KiB

View file

@ -624,7 +624,7 @@ In \autoref{fig:cpu_mehrprozessor} besitzt jeder Kern einen eigenen Cache. Mögl
& $\ominus$ & Dieselben Daten müssen ggf. mehrfach in den Caches gehalten werden.
\\ [4ex]
$\ominus$ & komplexer Bus mit Zugriffsprotokoll (Zeitverlust zumindest bei Zugriffskollision)
$\ominus$ & komplexer Bus mit Zugriffsprotokoll\newline(Zeitverlust zumindest bei Zugriffskollision)
& $\oplus$ & einfache 1:1-Verbindungen (kein komplexes Zugriffsprotokoll)
\\ [2ex]
@ -634,7 +634,7 @@ In \autoref{fig:cpu_mehrprozessor} besitzt jeder Kern einen eigenen Cache. Mögl
\label{tbl:mehrprozessor_cache}
\end{table}
Abhilfe für Inkonsistenz bei mehreren Caches und Mehrprozessorsystemen:
Abhilfe für Inkonsistenzen bei mehreren Caches und Mehrprozessorsystemen:
\begin{itemize}[noitemsep]
\item gemeinsamer Cache (ungünstige Performance aufgrund eines Bus)
@ -642,3 +642,171 @@ Abhilfe für Inkonsistenz bei mehreren Caches und Mehrprozessorsystemen:
\end{itemize}
Tatsächlich haben moderne \acsp{CPU} beim L1-Cache getrennte Caches für jeden Kern und beim L3-Cache einen gemeinsamen Cache. Ob eine Snoop-Logik verwendet wird, ist davon abhängig, ob es für das Level notwendig ist oder nicht.
\section{Hauptspeicher-Organisation}
Ein \acl{HS}-Wort wird über eine \acl{HSA} (binäre, ganze, nicht negative Zahl) angesprochen.
Jedes \acl{HS}-Wort hat eine feste Wortbreite (im besten Fall gleich der \acs{CPU}-Wortbreite, also 64-Bit).
Im folgenden gehen wir von 1-Bit-Worten aus:
\begin{center}
$0\leq \text{\acs{HSA}} \leq (\text{\acs{HS}-Größe in Worten}) - 1$
\end{center}
Ein 1-Bit-Kondensatorspeicher wird in \autoref{fig:hs_kondensator} gezeigt. Für jedes \acl{HS}-Wort gibt es eine Select-Leitung. Für jedes Bit des Wortes gibt es einen Kondensator und einen Transistor. Diese werden dann parallel geschaltet.
Mehrere 1-Bit-Worte hängen an der selben Datenleitung, werden aber über unterschiedliche Select-Leitungen angesteuert.
\begin{figure}[!ht]
\centering
\includegraphics[width=\textwidth-4cm]{./Bilder/HS_Kondensator.png}
\caption{Hauptspeicher -- 1-Bit-Kondensatorspeicher}
\label{fig:hs_kondensator}
\end{figure}
Um aus der $n$-Bit-\acs{HSA} $2^n$ Select-Leitungen zu erzeugen, welche die Bits abfragen, ist ein $n:2^n$-Decoder notwendig.
In \autoref{fig:4_16_dekoder} wird ein 4:16-Decoder mit entsprechender Wertetabelle gezeigt.
\begin{figure}[!ht]
\centering
\includegraphics[width=7cm]{./Bilder/4_16_Dekoder.png}
\medskip
\begin{tabular}{cccc|cccccccccccccccc}
$a_3$ & $a_2$ & $a_1$ & $a_0$ & $s_{15}$ & $s_{14}$ & $s_{13}$ & $s_{12}$ & $s_{11}$ & $s_{10}$ & $s_{9}$ & $s_{8}$ & $s_{7}$ & $s_{6}$ & $s_{5}$ & $s_{4}$ & $s_{3}$ & $s_{2}$ & $s_{1}$ & $s_{0}$ \\ \midrule
0 & 0 & 0 & 0 & & & & & & & & & & & & & & & & 1 \\
0 & 0 & 0 & 1 & & & & & & & & & & & & & & & 1 & \\
0 & 0 & 1 & 0 & & & & & & & & & & & & & & 1 & & \\
0 & 0 & 1 & 1 & & & & & & & & & & & & & 1 & & & \\
0 & 1 & 0 & 0 & & & & & & & & & & & & 1 & & & & \\
0 & 1 & 0 & 1 & & & & & & & & & & & 1 & & & & & \\
0 & 1 & 1 & 0 & & & & & & & & & & 1 & & & & & & \\
0 & 1 & 1 & 1 & & & & & & & & & 1 & & & & & & & \\
1 & 0 & 0 & 0 & & & & & & & & 1 & & & & & & & & \\
1 & 0 & 0 & 1 & & & & & & & 1 & & & & & & & & & \\
1 & 0 & 1 & 0 & & & & & & 1 & & & & & & & & & & \\
1 & 0 & 1 & 1 & & & & & 1 & & & & & & & & & & & \\
1 & 1 & 0 & 0 & & & & 1 & & & & & & & & & & & & \\
1 & 1 & 0 & 1 & & & 1 & & & & & & & & & & & & & \\
1 & 1 & 1 & 0 & & 1 & & & & & & & & & & & & & & \\
1 & 1 & 1 & 1 & 1 & & & & & & & & & & & & & & &
\end{tabular}
\caption{Hauptspeicher -- 1-Bit-Kondensatorspeicher}
\label{fig:4_16_dekoder}
\end{figure}
Es müssen alle Minterme gebildet werden.
Die \acs{DNF} ist für jedes $s_i$ gleichzeitig die \acs{DMF} (da sie aus nur einem Minterm besteht). \newline
Somit besteht der $n:2^n$ Decoder aus genau $2^n$ Mintermen mit jeweils $n$ Literalen.
\begin{tabular}{@{}ll}
\textsf{\textbf{Zeitaufwand}}: & 1~\acs{GLZ} ($O(1)$) und damit perfekt \\ [1ex]
\textsf{\textbf{Hardwareaufwand}}: & $n\cdot 2^n$ Transistoren
\end{tabular}
\textbf{\textsf{Hardwareaufwand für Speicher und Decoder}}: \newline
Am Beispiel vom Apple \RNum{2}/C64/\ldots: 16~Bit~\acs{HSA}, 8~Bit~Worte
\begin{itemize}
\item[$\Rightarrow$] $2^{16}$ 8-Bit-Worte: 65536~Byte = 512~kBit Speicher
\item[$\Rightarrow$] für Speicher: 1 Mio. Bauelemente \newline
für $16:2^{16}$ Decoder: $16\cdot 2^{16}$ Transistoren $\approx$ 1 Mio. Transistoren
\item[$\Rightarrow$] der Decoder hat denselben Aufwand wie der Speicher!
\end{itemize}
\newpage % Nur für's Layout
\acs{PC} mit 32~Bit~\acs{CPU}:
\begin{itemize}[noitemsep]
\item[] 32~Bit = 4~Byte \acl{HS}-Wertgröße
\item[] 32~Bit-\acs{HSA}: $2^{32}$ \acs{HS}-Werte $\approx$ 4~Mrd. \acs{HS}-Werte
\end{itemize}
\bigskip
\begin{Tipp}
Intel-\acsp{CPU} adressieren nach wie vor jedes einzelne Byte und nicht \acl{HS}-Werte der Größe 4 oder 8~Byte.
\end{Tipp}
Eine Ideale 32~Bit~\acs{CPU} hätte $2^{32}$ Werte je 32~Bit:
\begin{itemize}[noitemsep]
\item[$\Rightarrow$] $2^{32}\cdot 32$~Bit $\approx$ 128~Mrd.~Bit Speicher
\item[$\Rightarrow$] 256 Mrd. Bauelemente Hardwareaufwand für \acl{HS}
\item[$\Rightarrow$] Hardwareaufwand für einen $32:2^{32}$ Decoder: $32\cdot 2^{32}$ Tr. = 128~Mrd. Transistoren.
\end{itemize}
Ideale 64~Bit~\acs{CPU} hätte $2^{64}$ Werte je 64~Bit:
\begin{itemize}[noitemsep]
\item[$\Rightarrow$] $2^{64}\cdot 64$~Bit $=2^{70}$ $\approx$ 1~Trilliarde~Bit
\item[$\Rightarrow$] 2 Trilliarden Bauelemente Hardwareaufwand für \acs{HS}.
\item[$\Rightarrow$] $64:2^{64}$ Decoder: $64\cdot 2^{64}$ Transistoren $\approx$ 1 Trilliarde Transistoren
\end{itemize}
In jedem Fall ist der Hardwareaufwand für den Decoder in derselben Größenordnung wie für den eigentlichen Hauptspeicher und damit sehr (zu) groß!
\textit{Abhilfe}: matrixförmige Speicherorganisation
\section{Matrixförmige Speicherorganisation}
Eine matrixförmige Speicherorganisation: zweidimensionale Anordnung der Speicherwerte in Zeilen und Spalten, siehe \autoref{fig:matrix_decoder} auf \autopageref{fig:matrix_decoder}.
\begin{figure}[!ht]
\centering
\includegraphics[width=\textwidth-5cm]{./Bilder/Matrix_Decoder.png}
\caption{Matrixdecoder}
\label{fig:matrix_decoder}
\end{figure}
$a_3a_2$ gibt die Zeilennummer an und $a_1a_0$ die Spaltennummer. Somit reicht es statt eines 4:16-Decoder einen 2:4 Zeilen- und einen 2:4 Spalten-Decoder zu verwenden.
\textbf{Aufwand} \newline
Anstatt eines 4:16-Decoder mit 64 Transistor, zwei 2:4-Decoder mit $2\cdot 8$ Transistoren = 16 Transistoren.
64-Bit \acs{HSA}: als $64:2^{64}$ Decoder: $2^{70}$ Transistoren \newline
als Matrix mit $2^{32}$ Zeilen und $2^{32}$ Spalten: \newline
$32:2^{32}$ Decoder mit jeweils $32\cdot 2^{32}$ Transistoren=$2^{37}$ Transistoren \newline
2 Stück: $2^{38}$ Transistoren: 256 Mrd. Transistoren
In linearer Organisation betrüge der Decoder-Aufwand das 4-Mrd.-fache! Damit ergibt sich eine große Einsparung beim Decoder-Aufwand!
\textit{Aber}: für die Realisierung des 2. Select-Eingangs wird ein weiterer Transistor je Bit benötigt \newline
$\Rightarrow$ dieselbe Größenordnung Zusatzaufwand wie Einsparung?
Statt eines Spalten-Decoders werden die Datenleitungen aller Speicherbits einer Spalte zusammengeschaltet (als jeweils eine Spalten-Datenleitung). Von diesen wird aber über einen Spalten-Multiplexer ein Spalten-Daten-Signal ausgewählt. Dies wird in \autoref{fig:matrix_multiplexer} dargestellt.
\begin{figure}[ht]
\centering
\includegraphics[width=\textwidth-4cm]{./Bilder/Matrix_Multiplexer.png}
\caption{Matrixmultiplexer}
\label{fig:matrix_multiplexer}
\end{figure}
\begin{description}
\item[$2^n:1$-MUX] Baustein, welcher aus $2^n$-Dateneingängen anhand einer $n$-stelligen Adresse eine Datenleitung auswählt und ausgibt.
\end{description}
$2^4:1$-MUX: Hat 4 Adresseingänge und $2^4=16$ Dateneingänge
\begin{figure}[!ht]
\centering
\includegraphics[width=\textwidth-2cm]{./Bilder/Schaltnetz_MUX.png}
\caption{Schaltnetz eines $4:1$-MUX}
\label{fig:schaltnetz_MUX}
\end{figure}
Realisierung über $2:4$ Decoder sowie 4 \code{UND} mit jeweils 2 Eingängen und ein \code{ODER} mit 4 Eingängen
$2^n:1$ MUX: \newline
\hspace*{5mm}ein $n:2^n$ Decoder \newline
\hspace*{5mm}$2^n$ \code{UND} mit jeweils 2 Eingängen \newline
\hspace*{5mm}ein \code{ODER} mit $2^n$ Eingängen \newline
\hspace*{5mm}Gesamtaufwand: \newline
\hspace*{5mm}$n\cdot 2^n+2\cdot 2^n+2^n$ Transistoren \newline
\hspace*{5mm}$=(n+3)\cdot 2^n$ Transistoren \newline\todo{Formatieren}
Insgesamt braucht man für einen kleinen Decoder und einem kleinen Multiplexer immer noch deutlich weniger Hardwareaufwand wie für einen großen Decoder.
Vor den Multiplexer kann ein Cache geschaltet werden, sodass eine ganze \acs{HSS} (=Matrixzeile) eingelesen werden kann.
\subsection{Gründe für Matrixorganisation}
\begin{enumerate}
\item weniger Aufwand für Adresscodecodierung
\item Einlesen einer ganzen \acs{HSS} (=Matrixzeile) in den Cache
\item zeilenweiser Refresh des \acs{HS} (wortweiser Refresh-Zyklus dauert viel zu lange)
\end{enumerate}