\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}
