Fix some typos

inc/6.implementation.tex

@@ -49,13 +49,13 @@ A \texttt{memref\_t} can either represent an instruction, a data reference or a
 Besides of the type, the \revabbr{process identifier}{PID} and \revabbr{thread identifier}{TID} of the initiating process and thread is included in every record.
 For an instruction marker, the size of the instruction as well as the virtual address of the instruction in the memory map is provided.
 For data references, the address and size of the desired access is provided as well the \revabbr{program counter}{PC} from where it was initiated.
-In offline mode, DrCacheSim stores the current mapping of all binary executables and shared libraries in a seperate file, so that it is possible to decode named instructions even after the application has exited.
+In offline mode, DrCacheSim stores the current mapping of all binary executables and shared libraries in a separate file, so that it is possible to decode named instructions even after the application has exited.
 In case of online tracing, the analyzer has to inspect the memory of the client-side process for this.
 
 Analysis tools implement the \texttt{analysis\_tool\_t} interface as this enables the analyzer to forward a received record to multiple tools in a polymorphic manner.
 In particular, the \texttt{process\_memref\_t()} method of any tool is called for every incoming record.
 
-The newly developed DRAMTracer tool creates for every thread of the application a seperate trace file.
+The newly developed DRAMTracer tool creates for every thread of the application a separate trace file.
 As it is not known how many threads an application will spawn, the tool will listen for records with new TIDs that it did not register yet.
 For every data reference, a new entry in the corresponding trace file is made which contains the size and the physical address of the access, whether it was a read or write, and also a count of (computational) instructions that have been executed since the last reference.
 This instruction count is used to approximate the delay between the memory accesses when the trace is replayed by DRAMSys.
@@ -105,8 +105,7 @@ For the DbiPlayer, an additional interconnect module will bundle up all \\ \text
 
 As the memory accesses are directly extracted from the executed instructions, simply sending a transaction to the DRAM subsystem for every data reference would neglect the caches of today's processors completely.
 Therefore, also a cache model is required whose implementation will be explained in more detail in section \ref{sec:cache_implementation}.
-Modern cache hierarchies compose of 3 cache levels: 2 caches for every processor core, the L1 and L2 cache, and one cache that is shared across all cores, the L3 cache.
-% (vlt hier Literaturreferenz)
+Many modern cache hierarchies compose of 3 cache levels: 2 caches for every processor core, the L1 and L2 cache, and one cache that is shared across all cores, the L3 cache.
 This hierarchy is also reflected in the DbiPlayer as shown in Figure \ref{fig:dbiplayer_with_caches}.
 
 \begin{landscape}
@@ -179,7 +178,9 @@ It is to note that the current implementation does not utilize a snooping protoc
 Therefore, cache coherency is not guaranteed and memory shared between multiple processor cores will result in incorrect results as the values are not synchronized between the caches.
 However, it is to expect that this will not drastically affect the simulation results for applications with few shared resources.
 The implementation of a snooping protocol is a candidate for future improvements.
-%However, it is to expect that this will not drastically affect the simulation results.
 
-\subsection{A New Trace Player Interface}
+\subsection{Trace Player Interface}
 \label{sec:traceplayer_interface}
+
+\subsection{Interconnect}
+\label{sec:interconnect}