76 lines
3.7 KiB
TeX
76 lines
3.7 KiB
TeX
\documentclass[../../main.tex]{subfiles}
|
|
|
|
\begin{document}
|
|
|
|
\section{The Core}
|
|
|
|
The core implements the \instrset{} architecture as specified by the RISC-V standard~\cite{riscv-spec-unprivileged}.
|
|
|
|
\begin{figure}[h]
|
|
\includegraphics[width=\textwidth]{core_diagram.png}
|
|
\caption{Block diagram of the CPU core}
|
|
\label{fig:core-diagram}
|
|
\end{figure}
|
|
|
|
As can be seen in \autoref{fig:core-diagram}, it is constructed according to the traditional stages of a RISC pipeline:
|
|
|
|
\begin{description}
|
|
\item[Fetch] fetches the next instruction from memory.
|
|
\item[Decode] decodes the instruction into its constituent parts. At the same time, operand values are loaded from any required registers.
|
|
\item[Execute] performs the action required by the instruction, such as math performed by the Arithmetic Logic Unit (ALU) or writing to Control and Status Registers (CSRs).
|
|
\item[Memory] loads values from or stores values to the system's main memory or interacts with memory-mapped hardware devices.
|
|
\item[Writeback] stores a potential result value from Execute or Memory stages to the destination register.
|
|
\end{description}
|
|
|
|
\subsection{Control}
|
|
|
|
\entityheader{control}
|
|
|
|
The control unit is responsible for coordinating subcomponents and the data flow between them. Internally, it is based on \icode{instruction\_info\_t} structures, which contain all the information required to pass an instruction along the different pipeline stages. Before the fetch stage, when an instruction is first scheduled, it contains only the instruction's address (because nothing else is known about it). Then, information is added incrementally by the different stages.
|
|
|
|
\subsection{Decoder}
|
|
|
|
\entityheader{decoder}
|
|
|
|
The decoder receives an instruction and interprets it. Among others, it determines
|
|
|
|
\begin{itemize}
|
|
\item The source and destination register addresses
|
|
\item The pipeline stages that need to be run for the instruction
|
|
\item The ALU operation, if any
|
|
\item Whether the instruction should branch, and if so, under what condition
|
|
\end{itemize}
|
|
|
|
\subsection{Registers}
|
|
|
|
\entityheader{registers}
|
|
|
|
The registers store the 32 general-purpose values required by \instrset{} (each 32-bit wide). They are accessible through two read ports and one write port. As specified by the RISC-V standard, the first register (\icode{x0}) is hard-wired to 0, and any writes to it are ignored.
|
|
|
|
\subsection{Arithmetic and Logic Unit (ALU)}
|
|
\label{sec:core-alu}
|
|
|
|
\entityheader{alu}
|
|
|
|
The ALU contains a math/logic unit as well as a comparator. It is used both explicitly by instructions such as \icode{add} or \icode{shiftl}, as well as to add offsets to base addresses for memory instructions and to decide whether an instructions should branch.
|
|
|
|
\subsection{Control and Status Registers (CSR)}
|
|
|
|
\entityheader{csr}
|
|
|
|
The control and status registers contain configurations relevant to the core itself. For example, they can be used to control interrupts.
|
|
|
|
\subsection{Memory Arbiter}
|
|
|
|
\entityheader{memory_arbiter}
|
|
|
|
Since both fetch and memory stages need to access the same system memory, access to this common resource has to be controlled. The memory arbiter acts as a proxy for both fetch and data memory requests and stalls either until the other one completes.
|
|
|
|
\subsection{Exception Control}
|
|
|
|
\entityheader{exception_control}
|
|
|
|
Several components in the core may raise a synchronous exception when an unexpected error (such as a malformed instruction or an unaligned memory access) occurs. Additionally, asynchronous interrupts (like from a timer or a UART) can be triggered externally. When an exception or an enabled interrupt is registered, program flow is diverted to the trap handler, defined using the machine trap vector (\icode{mtvec}) CSR.
|
|
|
|
\end{document}
|