Add lilypond stuff

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}