Rework heading hierarchy
This commit is contained in:
parent
103a8e3d19
commit
1eaddf7d3d
3 changed files with 12 additions and 13 deletions
|
@ -127,6 +127,7 @@ geschlechtsunabh"angig verstanden werden soll.
|
|||
\clearpage
|
||||
%\MR\input{sections/Kapitel/MR/EntwicklungAufgaben.tex}
|
||||
|
||||
\part{FPGA-based System on Chip (SoC)}
|
||||
\subfile{sections/soc/soc.tex}
|
||||
\subfile{sections/core/core.tex}
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
\begin{document}
|
||||
|
||||
\part{The Core}
|
||||
\section{The Core}
|
||||
|
||||
The core implements the \instrset{} architecture as specified by the RISC-V standard~\cite{riscv-spec-unprivileged}.
|
||||
|
||||
|
@ -16,7 +16,7 @@ It is constructed according to the traditional RISC pipeline:
|
|||
\item[Writeback] stores a potential result value from Execute or Memory stages to the destination register.
|
||||
\end{description}
|
||||
|
||||
\section{Overview}
|
||||
\subsection{Overview}
|
||||
|
||||
\begin{figure}
|
||||
%\includegraphics[width=\textwidth]{core_diagram.png}
|
||||
|
@ -24,13 +24,13 @@ It is constructed according to the traditional RISC pipeline:
|
|||
\caption{Block diagram of the CPU core}
|
||||
\end{figure}
|
||||
|
||||
\section{Control}
|
||||
\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.
|
||||
|
||||
\section{Decoder}
|
||||
\subsection{Decoder}
|
||||
|
||||
\entityheader{decoder}
|
||||
|
||||
|
@ -43,32 +43,32 @@ The decoder receives an instruction and interprets it. Among others, it determin
|
|||
\item Whether the instruction should branch, and if so, under what condition
|
||||
\end{itemize}
|
||||
|
||||
\section{Registers}
|
||||
\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.
|
||||
|
||||
\section{Arithmetic and Logic Unit (ALU)}
|
||||
\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.
|
||||
|
||||
\section{Control and Status Registers (CSR)}
|
||||
\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.
|
||||
|
||||
\section{Memory Arbiter}
|
||||
\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.
|
||||
|
||||
\section{Exception Control}
|
||||
\subsection{Exception Control}
|
||||
|
||||
\entityheader{exception_control}
|
||||
|
||||
|
|
|
@ -1,9 +1,7 @@
|
|||
\documentclass[../../Diplomschrift.tex]{subfiles}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\part{Meta}
|
||||
\section{History}
|
||||
\section{Development History}
|
||||
|
||||
The project started out with the desire to build a CPU from scratch. Examples such as The NAND Game~\cite{nandgame} and Ben Eater's Breadboard Computer series~\cite{breadboard_computer} served as inspirations and guidance during development.
|
||||
|
||||
|
@ -54,7 +52,7 @@ Others & SD card, VGA & Ethernet \\
|
|||
|
||||
While the Digilent board offers fewer IO options, the DDR3 memory can be interfaced using Free memory cores and allows for much larger programs to be loaded, possibly even a full operating system. The missing VGA port has been substituted by an HDMI-compatible DVI interface that is accessible through one of the high-speed PMOD connectors.
|
||||
|
||||
\section{Tooling}
|
||||
\section{FPGA Tooling}
|
||||
|
||||
FPGA design is done using a Hardware Description Language (HDL). The two most well-known HDLs are Verilog and VHDL (VHSIC (Very high speed integrated circuit) HDL). As part of our studies at HTL, we exclusively worked with VHDL. For this reason, and because VHDL offers a better type system, it was chosen as the language of choice for the project.
|
||||
|
||||
|
|
Loading…
Reference in a new issue