SystemC and DRAMSys additions.
This commit is contained in:
@@ -36,41 +36,47 @@ TLM abstracts the modeling of the communication between modules using so-called
|
||||
In contrast to pin and cycle accurate models, this greatly reduces the simulation overhead at the cost of reduced accuracy.
|
||||
|
||||
Modules communicate with each other through \textit{initiator} sockets and \textit{target} sockets.
|
||||
A processor for example sends requests to a memory using its initiator socket, whereas the memory responds trough its target socket.
|
||||
Interconnect modules, which can be used to model a bus, use both sockets to communicate with both the initiator and the target modules.
|
||||
A processor, for example, sends requests to a memory using its initiator socket, whereas the memory responds trough its target socket.
|
||||
Interconnect modules, which can be used to model a bus, use both sockets to communicate with both initiator and the target modules.
|
||||
This concept is illustrated in figure \ref{fig:tlm}.
|
||||
|
||||
The transaction object itself is a \revabbr{generic payload}{GP}, which consists of address, command, status and other information as well as the actual data to transfer.
|
||||
GPs are transferred as references, avoiding the need to copy them between the modules.
|
||||
The transaction object itself is a \revabbr{generic payload}{GP}, which consists of the target address, whether the transaction is a read or write command, status information and other transaction parameters as well as the actual data to transfer.
|
||||
GPs are passed along as references, avoiding the need to copy them between the modules.
|
||||
|
||||
\input{img/thesis.tikzstyles}
|
||||
\begin{figure}[!ht]
|
||||
\begin{center}
|
||||
\tikzfig{img/tlm}
|
||||
\caption{Forward and backward path between TLM sockets\cite{Menard2017}. $\blacksquare$ denotes an initiator socket, $\square$ denotes a target socket.}
|
||||
\caption[Forward and backward path between TLM sockets\cite{Menard2017}.]{Forward and backward path between TLM sockets\cite{Menard2017}. $\blacksquare$ denotes an initiator socket, $\square$ denotes a target socket.}
|
||||
\label{fig:tlm}
|
||||
\end{center}
|
||||
\end{figure}
|
||||
|
||||
In the \revabbr{loosley-timed}{LT} coding style, a transaction is blocking, meaning it will be modeled by only one function call.
|
||||
This comes at the cost of limited timing accuracy as only the beginning and the end of the transaction are modeled as timing points and no other module can initiate transcations during this time.
|
||||
SystemC defines two coding styles for the use of TLM, called \revabbr{loosley-timed}{LT} and \revabbr{approximateley-timed}{AT}.
|
||||
In the LT coding style, a transaction is blocking, meaning it will be modeled by only one function call.
|
||||
This comes at the cost of limited timing accuracy as only the beginning and the end of the transaction are modeled as timing points and the initiator has to wait for the transaction to complete until it can make the next request.
|
||||
However, the fast simulation time, especially when \textit{temporal decoupling} with \textit{quantums} is used, makes it possible to use this coding style for rapid software development, like developing drivers for a simulated hardware component.
|
||||
For such a task the timing accuracy is sufficient.
|
||||
|
||||
The \revabbr{approximateley-timed}{AT} coding style is non-blocking and consists of a four-phase handshake:
|
||||
The AT coding style is non-blocking and therefore can be used to model with a higher timing accuracy than LT.
|
||||
This high accuracy makes it possible to use AT to conduct design space exploration on a hardware level.
|
||||
With AT, a special protocol is used that consists of a four-phase handshake:
|
||||
\texttt{BEGIN\_REQ},
|
||||
\texttt{END\_REQ},
|
||||
\texttt{BEGIN\_RESP} and
|
||||
\texttt{END\_RESP}.
|
||||
|
||||
When an initiator requests certain data from a target, it starts the transaction with the \texttt{BEGIN\_REQ} phase using its \texttt{nb\_transport\_fw()} method.
|
||||
The target now enqueues the payload into its \revabbr{payload event queue}{PEQ} and pretends it has received the payload after the delay, the initiator has specified.
|
||||
When the target is not ready yet to accept the requests, it defers its \texttt{END\_REQ} until it is.
|
||||
During this time, the initiator is blocked from sending further requests to other modules as the target applies \textit{back pressure} on the initiator.
|
||||
The target now enqueues the payload into its \revabbr{payload event queue}{PEQ} and pretends it has received the payload after the delay the initiator has specified.
|
||||
When the target is not yet ready to accept a new request, it defers its \texttt{END\_REQ} phase until it is.
|
||||
During this time, the initiator is blocked from sending further requests either to this or other modules as the target applies \textit{backpressure} on the initiator.
|
||||
This concept is called the \textit{exclusion rule}.
|
||||
|
||||
The target now prepares the response and sends the \texttt{BEGIN\_RESP} phase through its \texttt{nb\_transport\_bw()} method when the data is available.
|
||||
The initiator can now also apply back pressure to the target by deferring its \texttt{END\_RESP} phase.
|
||||
The initiator can now also apply backpressure to the target by deferring its \texttt{END\_RESP} phase.
|
||||
When the \texttt{END\_RESP} phase is received by the target, the transaction is completed.
|
||||
Figure \ref{fig:tlm_at} shows an exemplary handshake sequence diagram with all four phases.
|
||||
% hier komplexeres handshake beispiell
|
||||
Figure \ref{fig:tlm_at} shows an exemplary handshake sequence diagram of three different transactions.
|
||||
|
||||
\begin{figure}[!ht]
|
||||
\begin{center}
|
||||
@@ -80,8 +86,26 @@ Figure \ref{fig:tlm_at} shows an exemplary handshake sequence diagram with all f
|
||||
\end{center}
|
||||
\end{figure}
|
||||
|
||||
SystemC also supports additional user-defined phases through its \texttt{DECLARE\_EXTENDED\_PHASE()} macro.
|
||||
In contrast to the TLM-LT protocol, TLM-AT makes it possible model pipelining of transactions; multiple transactions can be processed by a target at one time.
|
||||
SystemC defines various special cases and shortcuts that can be used troughout the protocol.
|
||||
Both in the \texttt{BEGIN\_REQ} phase as well as in the \texttt{BEGIN\_RESP} phase, it is possible for the target to skip the \texttt{END\_REQ} phase or for the initiator to skip the \texttt{END\_RESP} phase respectively using the return value of the forward or backward transport function call.
|
||||
For this the return type \texttt{tlm\_sync\_enum} has to be set to \texttt{TLM\_UPDATED} instead of \texttt{TLM\_ACCEPTED} in the normal case.
|
||||
|
||||
Besides using the return path to skip the \texttt{END\_REQ} phase, it is possible for the target to directly respond with the \texttt{BEGIN\_RESP} phase.
|
||||
The initiator has to react accordingly and must detect that the \texttt{END\_REQ} has been skipped.
|
||||
However, since the initiator is blocked due to backpressure, this shortcut should only be used if the response is ready to send after a very short delay.
|
||||
Another form of this shortcut, is the combination with the return path of the forward transport function call.
|
||||
Here, the return path is used to directly send the \texttt{BEGIN\_REQ} phase, without invoking the backward transport function, reducing the required number of transport calls to only two.
|
||||
|
||||
The last shortcut, that can be made is the so-called \textit{early completion}.
|
||||
When the target receives the \texttt{BEGIN\_REQ} phase, it can already place the requested data into the payload and pass \texttt{TLM\_COMPLETED} as the return value back to the initiator.
|
||||
This notifies that the whole transaction is already completed at this point, so no further transport calls are required.
|
||||
Note that this form of early completion is very similar to the LT coding style, where a transaction is modeled using only one function call.
|
||||
Early completion can also be used by the initiator to skip the \texttt{END\_REQ} phase.
|
||||
Here, \texttt{TLM\_COMPLETED} is returned during the backward transport call and thus, the target experiences no backpressure from the initiator.
|
||||
|
||||
SystemC also supports additional user-defined phases through its \texttt{DECLARE\_EXTENDED\_\\PHASE()} macro.
|
||||
In contrast to the TLM-LT protocol, TLM-AT allows model pipelining of transactions; multiple transactions can be processed simultaneously by one target.
|
||||
The responses also do not need to be in the same order as the initiator has sent them: they can be \textit{out out order}.
|
||||
|
||||
The TLM-AT protol is the used protocol to implement the processor model and the cache model in section \ref{sec:implementation} of this thesis.
|
||||
The TLM-AT coding style is the used protocol to implement the processor model and the cache model in section \ref{sec:implementation} of this thesis.
|
||||
Also, some of the earlier described shortcuts are taken advantage of throughout those models.
|
||||
|
||||
Reference in New Issue
Block a user