[Skript] Fixes
This commit is contained in:
parent
3bebdbe65c
commit
ceab012b8d
GPG key ID:
AA6B4FC2A2C4329A
3 changed files with 44 additions and 50 deletions
Binary file not shown.
|
Before Width: | Height: | Size: 68 KiB After Width: | Height: | Size: 81 KiB |
|
|
@ -386,7 +386,7 @@ In der Realität werden natürlich nicht alle Vollkonjunktionen benötigt, sonde
|
|||
\newpage % Nur für's Layout
|
||||
|
||||
\begin{Achtung}
|
||||
Im folgenden wird fälschlicherweise von einem Aufwand $O(n^2\cdot 2^n)$ ausgegangen. Richtig wäre $O=(n^2\cdot 4^n)$. Herr Röthig hat die $O$-Notation falsch vereinfacht. Der 2015er Jahrgang hat dies \enquote{noch falscher} gemacht und zu $O(4^n)$ vereinfacht.
|
||||
Im folgenden wird fälschlicherweise von einem Aufwand $O(n^2\cdot 2^n)$ ausgegangen. Richtig wäre $O(n^2\cdot 4^n)$. Herr Röthig hat die $O$-Notation falsch vereinfacht. Der 2015er Jahrgang hat dies \enquote{noch falscher} gemacht und zu $O(4^n)$ vereinfacht.
|
||||
\end{Achtung}
|
||||
|
||||
Der Hardwareaufwand steigt beim $n$-Bit-\acs{CLA-PA} überexponentiell mit $n$.
|
||||
|
|
@ -473,7 +473,7 @@ $\Rightarrow$ damit ist das $n$ der nicht-\acs{CLA-PA} noch klein $\Rightarrow$
|
|||
\newpage % Für das Layout
|
||||
|
||||
\section{Serielladdierer} \index{Serielladdierer}
|
||||
\textit{Idee}: Angelehnt an die Verfahrensweise des Menschen sollen die Stellen der beiden Summanden nacheinander (und nicht gleichzeitig) addiert werden. Dadurch wird nur \textbf{ein} \acf{VA} und mehrere \acf{SR} benötigt. Daher ist der \acf{SA} ein Schaltwerk, kein Schaltnetz! \autoref{fig:serielladdierer} zeigt das Schaltwerk eines Serielladdierer.
|
||||
\textit{Idee}: Angelehnt an die Verfahrensweise des Menschen sollen die Stellen der beiden Summanden nacheinander (und nicht gleichzeitig) addiert werden. Dadurch wird nur \textbf{ein} \acf{VA} und mehrere \acf{SR} benötigt. Daher ist der \acf{SA} ein Schaltwerk, kein Schaltnetz! \autoref{fig:serielladdierer} zeigt das Schaltwerk eines Serielladdierers.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
|
|
@ -571,12 +571,12 @@ Der Zeitaufwand für einen $n$-Bit-\acl{SA} beträgt $n$ Taktzyklen, also $O(n)$
|
|||
\textit{Ist dies wie beim \acs{RC-PA}?} \newline
|
||||
Jein, denn $1$ Taktzyklus dauert deutlich mehr als doppelt solang wie die Berechnung des \acs{VA} (Sicherheitsmargen!). Beispiel: 1 Taktzyklus > \circa{10}~\acs{GLZ} $\Rightarrow$ fünffache Berechnungszeit des \acs{RC-PA}
|
||||
|
||||
\subsection{Hardwareaufwand ($N$-Bit-SA)}
|
||||
\subsection{Hardwareaufwand ($n$-Bit-SA)}
|
||||
|
||||
\begin{tabular}{@{}l@{}l}
|
||||
1 \acs{VA} & $ =18$ Transistoren \\
|
||||
2 \acs{D-FF} = $2\cdot 6$ & $ =12$ Transistoren. \hspace*{12.5mm} \textit{(siehe \autoref{fig:schieberegister})} \\
|
||||
3 $n$-Bit-\acs{SR} & $ =3\cdot 6n = 18n$ Transistoren \textit{(siehe \autoref{fig:aufwand_dff})} \\
|
||||
2 \acs{D-FF} = $2\cdot 6$ & $ =12$ Transistoren. \hspace*{12.5mm} \textit{(siehe \autoref{fig:aufwand_dff})} \\
|
||||
3 $n$-Bit-\acs{SR} & $ =3\cdot 6n = 18n$ Transistoren \textit{(siehe \autoref{fig:schieberegister})} \\
|
||||
Takterzeugung~~ & \textit{(im folgenden nicht näher betrachtet)} \\
|
||||
\textbf{gesamt} & $18n+30$ Transistoren
|
||||
\end{tabular}
|
||||
|
|
@ -729,7 +729,7 @@ Wie in \autoref{fig:serielladdierer_hw_optimierung} zu sehen ist, wird ein Schie
|
|||
\begin{table}
|
||||
\centering
|
||||
\begin{tabular}{c|c|c}
|
||||
n & \acs{RC-PA} (18n – 10) & \acs{SA} (12n +36) \\ \midrule
|
||||
n & \acs{RC-PA} ($18n - 10$) & \acs{SA} ($12n + 36$) \\ \midrule
|
||||
1 & 8 & 48 \\
|
||||
2 & 26 & 60 \\
|
||||
3 & 44 & 72 \\
|
||||
|
|
@ -747,7 +747,7 @@ Break-Even (\enquote{\textit{Gewinnschwelle}}): $18n -10 = 12n + 36 \Rightarrow
|
|||
\textbf{Mögliche Anwendung eines \acl{SA}}:
|
||||
\begin{itemize}[noitemsep]
|
||||
\item nicht im Rechenwerk der \acs{CPU} (aufgrund der Geschwindigkeit)!
|
||||
\item aber möglicherweise in \enquote{embedded system}, falls \zB Sensordaten sowieso seriell angeliefert werden
|
||||
\item aber möglicherweise in \enquote{embedded systems}, falls \zB Sensordaten sowieso seriell angeliefert werden
|
||||
\item[$\Rightarrow$] eventuell sind sogar weitere Hardware-Einsparungen möglich!
|
||||
\end{itemize}
|
||||
|
||||
|
|
@ -865,7 +865,7 @@ Ein $n\times m$-Bit-\acf{PM}, bspw. ein $5\times 4$-Bit-\acl{PM} ist in \autoref
|
|||
\end{figure}
|
||||
|
||||
\begin{Achtung}[frametitle={Hinweis zur Abbildung}]
|
||||
Unbedingt auf die \enquote{0} als Eingang achten! Ansonsten gibt es in der Klausur punktabzug! Bei unterschiedlicher Stellenanzahl sind Nullen aufzufüllen.
|
||||
Unbedingt auf die \enquote{0} als Eingang achten! Ansonsten gibt es in der Klausur punktabzug! Die \enquote{0} ist sogesehen der erste Übertrag.
|
||||
\end{Achtung}
|
||||
|
||||
\begin{Hinweis}
|
||||
|
|
@ -922,7 +922,7 @@ Demgegenüber sollte bei Verwendung von \acs{RC-PA} besser $n>m$ für geringeren
|
|||
\bigskip
|
||||
|
||||
\begin{Hinweis}[frametitle={Hinweis für die Klausur}]
|
||||
Den logarithmischen Aufwand für \acs{CLA-PA} auf \href{https://de.wikipedia.org/wiki/Paralleladdierer_mit_\%C3\%9Cbertragsvorausberechnung}{Wikipedia} nachschauen. Dies wird wahrscheinlich in der Klausur abgefragt! Unserer Variante hat exponentiellen Hardwareaufwand und konstanten Zeitaufwand. Die Variante auf \href{https://de.wikipedia.org/wiki/Paralleladdierer_mit_\%C3\%9Cbertragsvorausberechnung}{Wikipedia} nicht.
|
||||
Den logarithmischen Aufwand für \acs{CLA-PA} auf \href{https://de.wikipedia.org/wiki/Paralleladdierer_mit_\%C3\%9Cbertragsvorausberechnung}{Wikipedia} nachschauen. Dies wird zwar wahrscheinlich nicht in der Klausur abgefragt, aber er könnte abfragen, welche Alternativen es gibt. Unserer Variante hat exponentiellen Hardwareaufwand und konstanten Zeitaufwand. Die Variante auf \href{https://de.wikipedia.org/wiki/Paralleladdierer_mit_\%C3\%9Cbertragsvorausberechnung}{Wikipedia} nicht.
|
||||
\end{Hinweis}
|
||||
|
||||
\subsection{Seriellmultiplizierer} \index{Seriellmultiplizierer}
|
||||
|
|
@ -948,7 +948,7 @@ Motivation: Wir wollen eine noch engere Anlehung an das schriftliche Multiplikat
|
|||
|
||||
\begin{tabular}{c@{}ll}
|
||||
\textbullet~ & $n$-Bit-\acs{PA} $\Rightarrow$ $n$-Bit-\acs{RC-PA} & $\Rightarrow$ $18n-10$ Transistoren \\
|
||||
\textbullet~ & $n$ \code{UND} mit jeweils 2 Eingängen & $\Rightarrow$ 2 Transistoren \\
|
||||
\textbullet~ & $n$ \code{UND} mit jeweils 2 Eingängen & $\Rightarrow$ $2n$ Transistoren \\
|
||||
\textbullet~ & $2n$ \acsp{D-FF} & $\Rightarrow$ $12n$ Transistoren \\
|
||||
\textbullet~ & $2m$-Bit-\acs{SR} & $\Rightarrow$ $12m$ Transistoren \\
|
||||
\textbullet~ & \multicolumn{2}{@{}l}{Takterzeugung (wird im folgenden nicht berücksichtigt)}
|
||||
|
|
@ -968,8 +968,7 @@ Mindestdauer eines halben Taktzyklus: Berechnungszeit \enquote{innen}
|
|||
& $= 1+1+2n+1=2n+3$ \acs{GLZ} \\
|
||||
$\Rightarrow$ 1 Taktzyklus & $\gtrsim$ $4n+6$ \acs{GLZ} \\
|
||||
gesamt: & $\gtrsim m\cdot(4n+6)=4mn+6m=O(nm)$
|
||||
\end{tabular}\todo{Kontrollieren}
|
||||
|
||||
\end{tabular}
|
||||
|
||||
|
||||
\section{Division} \index{Division}
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@
|
|||
|
||||
\begin{table}[ht]
|
||||
\centering
|
||||
\begin{tabular}{p{29mm}|p{36mm}|p{17mm}|p{34mm}|p{23mm}}
|
||||
Speicher & von-Neumann-Rechner & Persistenz & Größe & Zugriffszeit \\ \midrule
|
||||
\begin{tabular}{p{29mm}|p{36mm}|p{19mm}|p{34mm}|p{23mm}}
|
||||
\textbf{Speicher} & \textbf{von-Neumann-Rechner} & \textbf{Persistenz} & \textbf{Größe} & \textbf{Zugriffszeit} \\ \midrule
|
||||
\acs{CPU}-Register & Zentraleinheit (Rechen- und Steuerwerk) & flüchtig & $<1kB$ Byte & $\approx$ 200ps \\ \midrule
|
||||
Cache \newline (\enquote{CPU-Cache}) & nicht vorhanden & flüchtig & \circa{4}MB \newline L1$\approx$64KB \newline L2$\approx$512KB & $\approx$ 10ns \\ \midrule
|
||||
Cache \newline (\enquote{CPU-Cache}) & nicht vorhanden & flüchtig & \circa{4}MB \newline L1 $\approx$ 64KB \newline L2 $\approx$ 512KB & $\approx$ 10ns \\ \midrule
|
||||
Hauptspeicher/ Primärspeicher & Speicherwerk & flüchtig & \circa{8}GB & $\approx$ 100ns \newline L1 schneller \\ \midrule
|
||||
Sekundärspeicher & Peripheriegeräte an Ein- und Ausgabewerk & nicht flüchtig & HDD: 3T \newline SSD: 512GB \newline opt.~\acs{LW}: bis~100GB \newline \acs{BLW}: wenige TB & HDD~$\approx10ms$ \newline SSD~$\approx 10\mu s$\newline opt.~\acs{LW}~$\approx 1s$ \newline \acs{BLW}~$\approx 1min$
|
||||
\end{tabular}
|
||||
|
|
@ -201,7 +201,7 @@ $\Rightarrow$ sobald das Zugriffsmuster Lokalität aufweist, ergibt sich eine be
|
|||
|
||||
\hspace*{-5mm}
|
||||
\begin{tabular}{p{32mm}|p{62mm}|p{62mm}}
|
||||
\textbf{Cachearchitektur} \newline \newline \textbf{Schreibstrategie}
|
||||
\textbf{Schreibstrategie} \newline \newline \textbf{Cachearchitektur}
|
||||
& \textbf{Write-Bac}k
|
||||
& \textbf{Write-Through} \\
|
||||
\midrule
|
||||
|
|
@ -226,10 +226,10 @@ $\Rightarrow$ sobald das Zugriffsmuster Lokalität aufweist, ergibt sich eine be
|
|||
\end{figure}
|
||||
|
||||
\begin{description}
|
||||
\item[\acf{HSS}] gleich große Speicheranteile des Hauptspeichers. Eine \acs{HSS} sollte $2^m$ \acfp{HSA} beinhalten, um eine einfache Umrechung von \acs{HSS}-Nummern und \acs{HSA} zu ermöglichen.
|
||||
\item[\acf{HSS}] Gleich große Speicheranteile des Hauptspeichers. Eine \acs{HSS} sollte $2^m$ \acfp{HSA} beinhalten, um eine einfache Umrechnung von \acs{HSS}-Nummern und \acs{HSA} zu ermöglichen.
|
||||
\item[\acf{CL}] Kopie einer \acl{HSS} im Cache
|
||||
\item[Tag] Die um $m$ niederwertigsten Bit gekürzte \acs{HSA}, welche der \acs{HSS}-Nummer entspricht.
|
||||
\item[Status] Zustandsinfo zur Cache-Line, \zB Valid-Flag und weiter Zustandsinfos abhängig von Verdrängungsstrategie
|
||||
\item[Status] Zustandsinfo zur Cache-Line, \zB Valid-Flag und weitere Zustandsinfos abhängig von Verdrängungsstrategie
|
||||
\item[Valid-Flag] Die Daten werden im Cache geändert und müssen noch in den \acs{HS} zurückgeschrieben werden (nur bei Write-Back-Schreibstrategie)
|
||||
\end{description}
|
||||
|
||||
|
|
@ -237,7 +237,7 @@ $\Rightarrow$ sobald das Zugriffsmuster Lokalität aufweist, ergibt sich eine be
|
|||
Jede \acl{HSS} kann in jeder \acl{CL} eingelagert werden (nicht gleichzeitig!)
|
||||
|
||||
\begin{itemize}
|
||||
\item[$\Rightarrow$] bei jedem Zugriff auf eine \acf{HSA} muss überprüft werden, ob die gekürzte \acs{HSA} einem der Tags von validen \acl{CL} entspricht!
|
||||
\item[$\Rightarrow$] bei jedem Zugriff auf eine \acf{HSA} muss überprüft werden, ob die gekürzte \acs{HSA} einem der Tags von validen \aclp{CL} entspricht!
|
||||
\item[$\Rightarrow$] Vergleichen der gekürzten \acs{HSA} mit allen Tags (von validen \acs{CL})
|
||||
\end{itemize}
|
||||
|
||||
|
|
@ -263,7 +263,7 @@ Hier: Schaltnetz, welches zwei Zahlen auf Gleichheit, Größer und Kleiner vergl
|
|||
Möchte man eine Wertetabelle für einen $n$-Bit-Komparator erstellen, sieht man, dass zu viele Zeilen in der Wertetabelle ($2^{2n}$\ldots) sind $\Rightarrow$ besser mit kaskadierbaren 1-Bit-Komparatoren
|
||||
|
||||
\textsf{\textbf{Komparator für Gleichheit}} \newline
|
||||
\textit{Hinweis}: im Cache reicht der Vergleich auf Gleichheit. \autoref{fig:cache_komparator_3} zeigt 1-Bit-Komparatoren für einen Gleichheits-Komparator.
|
||||
\textit{Hinweis}: Im Cache reicht der Vergleich auf Gleichheit. \autoref{fig:cache_komparator_3} zeigt 1-Bit-Komparatoren für einen Gleichheits-Komparator.
|
||||
\begin{figure}[!ht]
|
||||
\centering
|
||||
\includegraphics[width=9cm]{./Bilder/Aufwand_Komparator.png}
|
||||
|
|
@ -359,8 +359,8 @@ Viele Paare von \acs{HSS} können nicht gleichzeitig im Cache gehalten werden (b
|
|||
\textbf{Abhilfe}: \acf{nWAC}
|
||||
|
||||
\subsection{$n$-Wege-Assoziativ-Cache} \index{Cache!$n$-Wege-Assoziativ-Cache}
|
||||
Für jede \acs{HSS} gibt es genau $n$ \acl{CL}, in welche die \acs{HSS} eingelagert werden kann.
|
||||
Realisierung über $n$ \acs{DMC}, welche alle jeweils gleich aufgebaut sind.
|
||||
Für jede \acs{HSS} gibt es genau $n$ \aclp{CL}, in welche die \acs{HSS} eingelagert werden kann.
|
||||
Die Realisierung findet über $n$ \acs{DMC} statt, welche alle jeweils gleich aufgebaut sind.
|
||||
|
||||
|
||||
\subsection{Kollision}
|
||||
|
|
@ -411,7 +411,7 @@ Wenn eine \acs{HSS} in den Cache eingelagert werden soll, muss eine andere aus d
|
|||
|
||||
\bigskip
|
||||
\begin{Hinweis}
|
||||
Die Größe eines Speicherwertes in Bit wird nicht definiert und ist auch unerheblich für die folgenden Überlegungen
|
||||
Die Größe eines Speicherwertes bzw. Wortes in Bit wird nicht definiert und ist auch unerheblich für die folgenden Überlegungen
|
||||
\end{Hinweis}
|
||||
|
||||
\begin{figure}[!ht]
|
||||
|
|
@ -504,19 +504,16 @@ Wenn eine \acs{HSS} in den Cache eingelagert werden soll, muss eine andere aus d
|
|||
$\Rightarrow$ Hit in Cache A \acs{CL}-Nr. 2
|
||||
\end{paracol}
|
||||
|
||||
\columnratio{0.5}
|
||||
\begin{paracol}{2}
|
||||
\textbf{angefragte \acs{HSA}}: $0675_{10}$
|
||||
\begin{center}
|
||||
\textbf{angefragte \acs{HSA}}: $0675_{10}$
|
||||
|
||||
$\underbrace{~0~0~1~0~1~}_\text{Tag}\underbrace{~0~~~1~~~0~}_\text{\acs{CL}-Nr. 2}\underbrace{~0~0~1~1~}_\text{Pos. in \acs{CL} (3)}$
|
||||
\end{center}
|
||||
Tag in \acs{CL}-Nr. 2 von Cache A und Cache B sind verschieden vom angefragten Tag.
|
||||
|
||||
$\Rightarrow$ Miss $\Rightarrow$ sogar Kollision
|
||||
Tag in \acs{CL}-Nr. 2 von Cache A und Cache B \newline
|
||||
sind verschieden vom angefragten Tag.
|
||||
|
||||
$\Rightarrow$ Miss $\Rightarrow$ sogar Kollision \newline
|
||||
$\Rightarrow$ Verdrängung notwendig
|
||||
|
||||
$\Rightarrow$ Verdrängung notwendig
|
||||
\switchcolumn
|
||||
\end{paracol}
|
||||
|
||||
|
||||
\subsection{Verdrängungsstrategie} \label{sec:verdraengungsstrategie} \index{Cache!Verdrängungsstrategie}
|
||||
|
|
@ -563,7 +560,7 @@ Ständig genutzte Datenstücke werden genauso schnell verdrängt wie Daten, die
|
|||
Bei der \acf{LRU} Strategie wird die \acl{HSS}, auf welche am längsten nicht zugegriffen wurde, verdrängt.
|
||||
|
||||
\textit{Aufwand}: \newline
|
||||
Timestamp mit Update bei jedem Zugriff $\Rightarrow$ Die Suche bei Verdrängung ist zu aufwändig
|
||||
Timestamp mit Update bei jedem Zugriff $\Rightarrow$ Die Suche bei Verdrängung ist zu aufwändig!
|
||||
|
||||
\textit{Besser}:\newline
|
||||
Verwaltung als \textit{doppelt} verkettete Liste, \dash Zeiger auf Vorgänger \textit{und} Nachfolger in jeder \acs{CL}. Globalen Zeiger auf ersten und letzten Eintrag.
|
||||
|
|
@ -588,8 +585,6 @@ Bei der \acf{LFU} Strategie wird die \acl{HSS} verdrängt, welche bisher am selt
|
|||
$\Rightarrow$ Bei Verdrängung aufwändige Berechnung und Suche
|
||||
\end{paracol}
|
||||
|
||||
\newpage % Nur für's Layout
|
||||
|
||||
\textit{Problem (Zugriffsmuster)}: \newline
|
||||
Neu eingelagerte Seiten werden schnell wieder verdrängt, wenn sich der Zugriffszähler am Anfang nicht schnell genug erhöht und andere etablierte Seiten eine höhere Häufigkeit aufgrund vieler \enquote{alter} Zugriffe aufweisen.
|
||||
|
||||
|
|
@ -601,8 +596,8 @@ Mehrere Zugriffszähler in jeder \acs{CL} für die letzten $i$ Zeitscheiben.
|
|||
Dividieren ist damit überflüssig (alle Zeitscheiben sind gleich lang): Addition der mit $2^j$ gewichteten Zähler als \enquote{Häufigkeit} ($j=i-1$ für jüngste Zeitscheiben, $j=0$ für älteste Zeitscheibe).
|
||||
|
||||
\textit{Weiterhin}: \newline
|
||||
Bei der Verdrängung gibt ein Problem bei der Suche nach der niedrigsten \enquote{Häufigkeit}. \newline
|
||||
$\Rightarrow$ evtl. Lösung über eine bei Beginn jedes Zeitslots neu aufzubauende verkettete Liste. \newline
|
||||
Bei der Verdrängung gibt es ein Problem bei der Suche nach der niedrigsten \enquote{Häufigkeit}. \newline
|
||||
$\Rightarrow$ evtl. Lösung über eine bei Beginn jeden Zeitslots neu aufzubauende verkettete Liste. \newline
|
||||
\phantom{$\Rightarrow$ }Hier gibt es viel Platz für Optimierungen der \acs{CPU}-Hersteller.
|
||||
|
||||
\subsection{Cache bei Mehrprozessor-/Mehrkernsystemen} \index{Mehrkernprozessor}
|
||||
|
|
@ -620,7 +615,7 @@ In \autoref{fig:cpu_mehrprozessor} besitzt jeder Kern einen eigenen Cache. Mögl
|
|||
\begin{tabular}{@{}cp{7.6cm}|cp{7.6cm}}
|
||||
& \textbf{gemeinsamer Cache} & & \textbf{getrennter Cache} \\ \midrule
|
||||
|
||||
$\oplus$ & dieselben Daten für beide Kerne benötigt bedeutet nur einmaliges Einlagern im Cache (Platzvorteil).
|
||||
$\oplus$ & dieselben Daten für beide Kerne benötigt/bedeutet nur einmaliges Einlagern im Cache (Platzvorteil).
|
||||
& $\ominus$ & Dieselben Daten müssen ggf. mehrfach in den Caches gehalten werden.
|
||||
\\ [4ex]
|
||||
|
||||
|
|
@ -658,14 +653,14 @@ Mehrere 1-Bit-Worte hängen an der selben Datenleitung, werden aber über unters
|
|||
|
||||
\begin{figure}[!ht]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth-4cm]{./Bilder/HS_Kondensator.png}
|
||||
\includegraphics[width=\textwidth-52mm]{./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.
|
||||
In \autoref{fig:4_16_dekoder} wird ein $4:16$-Decoder mit entsprechender Wertetabelle gezeigt.
|
||||
|
||||
\begin{figure}[!ht]
|
||||
\centering
|
||||
|
|
@ -756,7 +751,7 @@ Eine matrixförmige Speicherorganisation: zweidimensionale Anordnung der Speiche
|
|||
$a_3a_2$ gibt die Zeilennummer an und $a_1a_0$ die Spaltennummer. Somit reicht es statt eines 4:16-Decoders einen 2:4~Zeilen- und einen 2:4~Spalten-Decoder zu verwenden.
|
||||
|
||||
\textbf{Aufwand} \newline
|
||||
Anstatt wie bei einem 4:16-Decoder mit 64 Transistoren beträgt der Aufwand bei zwei 2:4-Decodern mit $2\cdot 8$ Transistoren = 16 Transistoren.
|
||||
Anstatt wie bei einem $4:16$-Decoder mit 64 Transistoren beträgt der Aufwand bei zwei $2:4$-Decodern mit $2\cdot 8$ Transistoren = 16 Transistoren.
|
||||
|
||||
64-Bit \acs{HSA}: als $64:2^{64}$ Decoder: $2^{70}$ Transistoren
|
||||
|
||||
|
|
@ -792,7 +787,7 @@ Statt eines Spalten-Decoders werden die Datenleitungen aller Speicherbits einer
|
|||
\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
|
||||
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
|
||||
|
|
@ -806,7 +801,7 @@ Vor den Multiplexer kann ein Cache geschaltet werden, sodass eine ganze \acs{HSS
|
|||
|
||||
\subsection{Gründe für Matrixorganisation}
|
||||
\begin{enumerate}[noitemsep]
|
||||
\item weniger Aufwand für Adresscodecodierung
|
||||
\item weniger Aufwand für Adressdecodierung
|
||||
\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}
|
||||
Loading…
Reference in a new issue