diff options
Diffstat (limited to 'doc/rapport_final.tex')
| -rw-r--r-- | doc/rapport_final.tex | 186 |
1 files changed, 0 insertions, 186 deletions
diff --git a/doc/rapport_final.tex b/doc/rapport_final.tex deleted file mode 100644 index 6fc6a56..0000000 --- a/doc/rapport_final.tex +++ /dev/null @@ -1,186 +0,0 @@ -\documentclass[11pt, a4paper]{article} - -\usepackage[utf8]{inputenc} - -\usepackage[margin=1.0in]{geometry} -\usepackage[french]{babel} - -\newcommand{\prog}[1]{{\tt#1}} -\newcommand{\underscore}{$\_\,$} - -\begin{document} - - - -\title{Conception and realization of the VIVACE architecture - \\ \normalsize{\textsc{Projet de Système digital}}} -\author{A.Auvolat, E.Enguehard, J.Laurent} -\maketitle - - -The VIVACE\footnote{Virtually Infaillible VIVACE Automated Computing Environment} architecture is -a minimalistic 16 bits RISC microprocessor architecture, largely inspired by the MIPS -microprocessor. - - -The principal characteristics of the architecture are: - -\begin{itemize} -\item \textit{8 general-purpose registers}, which can hold 16 bits integers: \prog{Z, A, B, C, D, E, F, G} -\item \textit{16 bit memory addressing}, enabling the CPU to use up to $64kb$ of memory. -\end{itemize} - -In order to implement and run the architecture, the following programs have been written: - -\begin{itemize} -\item \textit{Netlist simulator} and \textit{netlist optimizer} -\item An \textit{OCaml library} for generating netlists from Caml code -\item The code for the \textit{CPU implementation} (written in Caml) -\item A \textit{monitor} which is used to interact dynamically with the netlist simulator -\item An \textit{assembler} which can be used to produce the ROM files run by the CPU. -\end{itemize} - -\section{How to run the VIVACE cpu} -\subsection{Preparation} - -All the tools described in the introduction must first be compiled: - -\begin{verbatim} - $ cd csim; make; cd .. - $ cd sched; make; cd .. - $ cd monitor; make; cd .. - $ cd asm; make; cd .. -\end{verbatim} - -To run the VIVACE CPU, type the following: - -\begin{verbatim} - $ cd cpu; make -\end{verbatim} - -\subsection{Monitor commands} - -You are now running the VIVACE CPU. The monitor accepts a few commands to control the simulation. -First, you must configure the monitor to communicate with the CPU. Type: - -\begin{verbatim} - t 0 - s 1 19 18 - d7 20 21 22 23 24 25 26 27 -\end{verbatim} - -The first command sets up the tick input (a tick is sent once every second on this input by the monitor). The -second command sets up the serial input/output. The third command sets up the 7-segment display (8 digits displayed). -Now, use the following commands to control the simulation: - -\begin{itemize} - \item \prog{a} run the simulation at full speed - \item \prog{m} run the simulation step by step (enter an empty command to run a step) - \item \prog{f <freq>} run the simulation at fixed frequency (frequency is dynamically ajusted so - this is not very accurate) - \item \prog{q} exit simulation -\end{itemize} - -The CPU recieves commands on the serial input. To send a command to the CPU, use the following syntax: - -\begin{verbatim} - :<cpu_command> -\end{verbatim} - -For instance: - -\begin{verbatim} - :Y2014 -\end{verbatim} - -These commands are essentially used to set one of the six variables \prog{YMDhms} ; the syntax is similar to the -example command given above. An empty CPU command tells the CPU to just tell us what time and what day it is. - - -\section{Program details} -\subsection{Generating netlists from Caml code} - -We have developped a library that enables us to easily generate netlists from Caml code. The Caml code we write -has the same abstraction level that MiniJazz has, but it is more comfortable to write circuits like this than -with MiniJazz code. - -The library functions are defined in \prog{cpu/netlist\_gen.mli}. Basically, we have created functions that build -the graph of logical operations. The abstract type \prog{t} is actually a closure to a function that adds the -required equation to a netlist program being built, therefore the generation of a netlist consists in two steps: -the generation of a closure graph that describes the graph of logical operations, and the execution of these -closures on a program which, at the beginning, has only the circuit inputs. The equations are progressively -added to the program when the closures are called. - -The VIVACE CPU has been entirely realized using this library. - -\subsection{The VIVACE CPU} - -\subsubsection{Control structure} - -The CPU is able to execute instructions that need several cycles to run. The two first cycles of an instruction's -execution are used to load that instruction (16 bits have to be read, ie two bytes). Most instructions finish -their execution on the second cycle, but some executions need more cycles to run: - -\begin{itemize} - \item Load and store instructions need one or two extra cycles - \item The multiplication operation needs as many cycles as the position - of the most-significant non-null bit in the second operand. - \item The division always runs on 16 cycles. -\end{itemize} - -The execution of instructions on several cycles is implemented using a ``control bit'' that cycles through -several steps: load instruction, various steps of instruction execution. A few of these step control bits -appear in the simulator, as CPU outputs: - -\begin{itemize} - \item \prog{read\_ilow}, \prog{read\_ihi} CPU is reading low byte/high byte of the instruction - \item \prog{ex\_instr} CPU begins execution of the instruction - \item \prog{ex\_finish} CPU finishes execution of the instruction (modified registers may only appear - in the monitor at the next step) -\end{itemize} - - -\subsubsection{ROM, RAM and MMIO} - -The CPU has uniform acces to a 64kb address space, which contains the ROM (\prog{0x0000-0x3FFF}), MMIO (\prog{0x4000-0x7FFF}) -and the RAM (\prog{0x8000-0xFFFF}). -The \prog{cpu\_ram} (\prog{cpu.ml}) subcircuit is basically a bunch of multiplexers that redirect reads and writes to the correct places. - -The serial input/output is implemented using one input and two outputs : - -\begin{itemize} - \item Input \prog{ser\_in} (8 bits) : when this input is non-null, the character entered is buffered by - the CPU. This buffer can be read by reading MMIO byte at address \prog{0x4100}. The buffer is reset to zero - on read. - \item Output \prog{ser\_in\_busy} (1 bit) : signals when the input buffer is nonzero (ie a character is - pending, waiting for the CPU to read and handle it). - \item Output \prog{ser\_out} (8 bits) : when non-null, the CPU is sending a character to the serial output. - This output can be written by writing MMIO byte at address \prog{0x4102}. -\end{itemize} - -The clock is also handled by MMIO : the CPU recieves a tick every second on input \prog{tick}. When a tick is -recieved, the tick buffer is incremented by one. This tick buffer can be read by reading MMIO word at address -\prog{0x4000}. When the word is read, the buffer is reset to zero. - -The 7-segment display is also handled by MMIO : the 8 digits can be modified by writing a byte to MMIO addresses -\prog{0x4200} to \prog{4207}. - -\subsubsection{The ALU} - -\subsection{The assembler} - -\subsection{The simulator and the monitor} - -The simulator is written in C for performance reasons. - -The monitor is a C program, using the curses library for output to the console. - -The simulator and the monitor communicate via Unix named pipes (FIFO's), which are created in -the files \prog{/tmp/sim2mon} and \prog{/tmp/mon2sim}. The synchronization of the two programs -has somewhat been problematic, due to incorrect use of \prog{scanf} making the programs hang. - -\subsection{The operating system} - -\section{Results and benchmarking} - -\end{document} |