diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/Makefile | 5 | ||||
| -rw-r--r-- | doc/plan_micro.pdf | bin | 80846 -> 80944 bytes | |||
| -rw-r--r-- | doc/plan_micro.tm | 3 | ||||
| -rw-r--r-- | doc/rapport_final.pdf | bin | 158834 -> 147180 bytes | |||
| -rw-r--r-- | doc/rapport_final.tex | 66 |
5 files changed, 60 insertions, 14 deletions
diff --git a/doc/Makefile b/doc/Makefile new file mode 100644 index 0000000..d220fc7 --- /dev/null +++ b/doc/Makefile @@ -0,0 +1,5 @@ + +all: rapport_final.pdf + +%.pdf: %.tex + pdflatex $< diff --git a/doc/plan_micro.pdf b/doc/plan_micro.pdf Binary files differindex d1e0dcc..8e45829 100644 --- a/doc/plan_micro.pdf +++ b/doc/plan_micro.pdf diff --git a/doc/plan_micro.tm b/doc/plan_micro.tm index 158ffb5..06d83fa 100644 --- a/doc/plan_micro.tm +++ b/doc/plan_micro.tm @@ -66,7 +66,8 @@ at 0x4000>|<cell|Clock ticker (incremented every tick, reset on read)>>|<row|<cell|byte at 0x4100>|<cell|Serial input (set when byte received, reset on read)>>|<row|<cell|byte at 0x4102>|<cell|Serial output - (sends byte immediately on write)>>>>>|Addresses MMIO> + (sends byte immediately on write)>>|<row|<cell|bytes 0x4200 to + 0x4207>|<cell|7-segment displayer>>>>>|Addresses MMIO> <section|Jeu d'instruction> diff --git a/doc/rapport_final.pdf b/doc/rapport_final.pdf Binary files differindex e18eec7..5da220f 100644 --- a/doc/rapport_final.pdf +++ b/doc/rapport_final.pdf diff --git a/doc/rapport_final.tex b/doc/rapport_final.tex index 67aa4c1..6fc6a56 100644 --- a/doc/rapport_final.tex +++ b/doc/rapport_final.tex @@ -23,14 +23,14 @@ a minimalistic 16 bits RISC microprocessor architecture, largely inspired by the microprocessor. -The principal characteristics of the architecture are : +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{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 : +In order to implement and run the architecture, the following programs have been written: \begin{itemize} \item \textit{Netlist simulator} and \textit{netlist optimizer} @@ -43,7 +43,7 @@ In order to implement and run the architecture, the following programs have been \section{How to run the VIVACE cpu} \subsection{Preparation} -All the tools described in the introduction must first be compiled : +All the tools described in the introduction must first be compiled: \begin{verbatim} $ cd csim; make; cd .. @@ -52,7 +52,7 @@ All the tools described in the introduction must first be compiled : $ cd asm; make; cd .. \end{verbatim} -To run the VIVACE CPU, type the following : +To run the VIVACE CPU, type the following: \begin{verbatim} $ cd cpu; make @@ -61,7 +61,7 @@ To run the VIVACE CPU, type the following : \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 : +First, you must configure the monitor to communicate with the CPU. Type: \begin{verbatim} t 0 @@ -71,7 +71,7 @@ First, you must configure the monitor to communicate with the CPU : 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 : +Now, use the following commands to control the simulation: \begin{itemize} \item \prog{a} run the simulation at full speed @@ -81,7 +81,7 @@ Now, use the following commands to control the simulation : \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 : +The CPU recieves commands on the serial input. To send a command to the CPU, use the following syntax: \begin{verbatim} :<cpu_command> @@ -106,7 +106,7 @@ 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 : +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. @@ -119,7 +119,7 @@ The VIVACE CPU has been entirely realized using this library. 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 : +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 @@ -129,11 +129,41 @@ their execution on the second cycle, but some executions need more cycles to run \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. +several steps: load instruction, various steps of instruction execution. A few of these step control bits +appear in the simulator, as CPU outputs: -The instruction decoding mechanism is in \prog{cpu.ml} which is well-commented. +\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} -\subsubsection{ROM, RAM and MMIO +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} @@ -141,6 +171,16 @@ The instruction decoding mechanism is in \prog{cpu.ml} which is well-commented. \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} |