% !TEX encoding = UTF-8 Unicode
% !TEX spellcheck = en_US
\documentclass{svproc}

\usepackage{paralist}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{calrsfs} % Für Kalligraphie-F
\newcommand{\bm}[1]{\boldsymbol{#1}}
\DeclareMathOperator{\arctantwo}{arctan2}
% Latex-Makros für häufig verwendete Formelzeichen
\newcommand{\ortvek}[4]{{ }_{(#1)}{\boldsymbol{#2}}^{#3}_{#4} }
\newcommand{\vek}[3]{\boldsymbol{#1}^{#2}_{#3}}
\newcommand{\rotmat}[2]{{{ }^{#1}\boldsymbol{R}}_{#2}}
\newcommand{\rotmato}[2]{{{ }^{#1}\boldsymbol{\overline{R}}}_{#2}}
\newcommand{\transp}[0]{{\mathrm{T}}}
\newcommand{\ks}[1]{{\mathcal{F}}_{#1}}

% Für Deutsche Umlaute
%\usepackage{ngerman}
\usepackage[utf8]{inputenc}

% Für Bilder
\usepackage{graphicx}
\usepackage{color}
\graphicspath{{./figures/}}

% to typeset URLs, URIs, and DOIs
\usepackage{url}
\def\UrlFont{\rmfamily}

\begin{document}

\mainmatter              % start of a contribution
%
\title{Resolution of Functional Redundancy for 3T2R Robot Tasks using Two Sets of \\Reciprocal Euler Angles}
%
\titlerunning{Reciprocal Euler Angles}  % abbreviated title (for running head)
%                                     also used for the TOC unless
%                                     \toctitle is used
%
\author{Moritz Schappler \and Svenja Tappe \and Tobias Ortmaier}
%
\authorrunning{Schappler et al.} % abbreviated author list (for running head)
%
%%%% list of authors for the TOC (use if author list has to be modified)
%\tocauthor{Moritz Schappler, Svenja Tappe, and Tobias Ortmaier}
%
\institute{Institute for Mechatronic Systems, Leibniz University Hannover, Germany,\\
    \email{moritz.schappler@imes.uni-hannover.de}}

\maketitle              % typeset the title of the contribution

%ABSTRACT
\begin{abstract}
Robotic tasks like welding or drilling with three translational and only two rotational degrees of freedom (``3T2R'') are of high industrial relevance but are ra\-ther scarcely addressed in scientific publications.
Existing solutions for the resolution of the functional redundancy of robotic manipulators with more than five axes performing these tasks either expand the full kinematic formulation or reduce it in intermediate steps.
This paper presents an approach to reduce the kinematic formulation from the start to solve the problem in a simpler way.
This is done by using a set of reciprocal Euler angles to describe the end-effector orientation and the orientation error in inverse kinematics.
\end{abstract}

%KEYWORDS
\begin{keywords}
functional redundancy, reciprocal Euler angles, \\ inverse kinematics, robot manipulators, five-DoF task, 3T2R task
\end{keywords}

\section{Introduction}
\label{sec:Intro}
Since the first papers in the 1980s, the fields of inverse kinematics \cite{GoldenbergBenFen1985} and the resolution of \emph{intrinsic} redundancy \cite{Yoshikawa1984} in robotics have been extensively elaborated upon.
Inverse kinematics for robot manipulators can be solved analytically for some structures and can be approached in general with gradient-based numeric methods at  joint position or joint velocity level.
Due to the nonlinearity of rotation at position level \cite{GoldenbergBenFen1985}, the latter is usually preferred.

Intrinsic redundancy is defined as a robot joint space dimension higher than the operational space dimension and functional redundancy is defined as an operational space dimension higher than the task space dimension, implying that there are more independent joint coordinates than task coordinates.

The kinematics of \emph{functionally} redundant robots performing tasks with five instead of six degrees of freedom (DoF) has drawn much less attention, even if many industrial relevant tasks only require 5-DoF such as the class of 3T2R-tasks where the tool for the task is axis-symmetric.
These tasks comprise amongst others arc welding \cite{HuoBar2005}, drilling \cite{ZhuQuCaoYan2013,GuoDonKe2015}, spray-painting \cite{FromGra2010}, milling \cite{MousaviGagBouRay2018}, laser-cutting and glueing and are transfered to a greater extend to robotic manipulators in the automotive or aviation industry.

Since standard industrial robots have six DoF, one degree of \emph{functional} redundancy exists which allows to improve performance characteristics of the robots as a secondary task while reaching a valid pose to perform one of the aforementioned primary tasks.
To be able to incorporate performance optimization into inverse kinematics via the well-established gradient projection method \cite{Yoshikawa1984}, either the joint space can be augmented or the task space can be reduced. % \cite{Huo2009}.
Augmenting the joint space is possible by virtually inserting an additional joint for the rotation around the task's axis of symmetry (``tool axis'') \cite{Baron2000}.
Reducing the task space can be performed by orthogonal decomposition of the end-effector twist \cite{HuoBar2005}, removing the row of the ``task frame Jacobian'' corresponding to the tool axis \cite{Zlajpah2017}, the construction of the Jacobian Nullspace based upon geometric properties of the task \cite{LegerAng2016} or constructing a cone or pyramid resulting from the tool axis with an additional range of tolerance for tilt angles \cite{FromGra2010}.

Another possibility for the resolution of the functional redundancy is a cascaded optimization where the inner loop calculates the inverse kinematics with standard methods and the outer loop optimizes the performance index.
The optimization can be performed by evaluating the index on a range of rotation angles around the tool axis \cite{ZhuQuCaoYan2013} or by using the incremental change of the rotation around the tool axis directly to adapt the joint angles  \cite{GuoDonKe2015}.

The choice of performance indices aims to improve the task execution with measures such as the joint positions quadratic \cite{HuoBar2005} or hyperbolic \cite{ZhuQuCaoYan2013} distances from their limits, singularity avoidance via Frobenius-norm condition number \cite{ZhuQuCaoYan2013}, squared condition number \cite{LegerAng2016} or a combination of manipulability and condition number of the Jacobian \cite{HuoBar2008}, stiffness \cite{GuoDonKe2015} or milling chatter stability margins \cite{MousaviGagBouRay2018}.

The characteristic length required to normalize the Jacobian for the performance indices can be either chosen constant regarding the robot geometry \cite{ZhuQuCaoYan2013} or as an additional optimization parameter \cite{LegerAng2016}.

The existing methods each have drawbacks that are avoided by using the new method presented in this paper:
\begin{compactitem}
    \item Augmenting the joint space \cite{Baron2000} increases the computational cost and can lead to an ill-conditioned Jacobian \cite{HuoBar2008}.
    \item Using a nested optimization \cite{ZhuQuCaoYan2013,GuoDonKe2015} does not allow using the well-proven gradient projection method.
    \item In \cite{Zlajpah2017} the tool-axis rotation of the end-effector has to be calculated and canceled out in the nullspace.
    \item Describing the tool axis with two points requires to define a distance between these points, which has to be chosen e.\,g. as the normalized Jacobian's characteristic length to gain a good conditioning of the optimization \cite{LegerAng2016}.
    \item All methods have a high mathematical level of abstraction e.\,g. using orthogonal decomposition \cite{HuoBar2008}, linear matrix inequalities and convex optimization \cite{FromGra2010}, rotation and component-selection of the vector part of the quaternion orientation error \cite{Zlajpah2017} or sequential quadratic programming \cite{LegerAng2016}.
\end{compactitem}

This paper transfers the velocity level approach from \cite{Zlajpah2017} to the position level and the orientation error is expressed in Euler angles instead of quaternions:

The absolute orientation of the end-effector and the corresponding orientation error between desired and actual end-effector orientation are expressed with two sets of Euler angles which are mutually reciprocal.
Reciprocity for sets of Euler angles is defined in this paper as successive rotations around intrinsic elementary axes of switched order.
By this definition, the rotation component belonging to the tool axis in 3T2R tasks is always the same for the absolute orientation and for the orientation error, respectively.
The effect of the tool axis can then be eliminated from the kinematic equations.
This allows to express the kinematics equations in minimal form which makes it easy to use the gradient projection method to incorporate performance indices in inverse kinematics.

The contributions of this paper are
\begin{compactitem}
    \item a new formulation for the kinematics problem for robot manipulators performing 3T2R-tasks,
    \item an application of the formulation leading to an efficient solution for inverse kinematics with functional redundancy,
    \item remarks on the implementation of gradients of and w.r.t. rotation matrices and its performance.
\end{compactitem}

The remainder of the paper is structured as follows: The idea of a kinematic description using sets of reciprocal Euler angles is elaborated upon in Sec.\,\ref{sec:RecEulAng}.
Their application in inverse kinematics of 3T2R tasks and in resolving the functional redundancy is shown in Sec.\,\ref{sec:RecEulAng_3T2R_app} and \ref{sec:ResFuncRed}.
Sec.\,\ref{sec:Conclusion} concludes the paper.

\section{Using Reciprocal Euler Angles for Robot Kinematics}
\label{sec:RecEulAng}

The core of solving the inverse kinematics problem of robot manipulators for tasks with only two rotational degrees of freedom is the nonlinearity of rotation.
Rotation can be described using rotation matrices, Euler angles, rotation angle/axis and its derivations like quaternions or the Rodrigues vector.
In contrast to all other notations, consecutive elementary rotations like Euler angles can be reduced to adapt for tasks only requiring two rotatory DoF.

\subsection{Kinematics Description}
\label{sec:RecEulAng_KinDesc}

A serial kinematic chain is described with the joint positions $\bm{q}$ and the forward kinematics
\vspace{-0.2em}
%
\begin{equation}
\bm{x} (\bm{q})
=
\bm{f} (\bm{q})
\label{equ:dirkin}
\end{equation}
%
giving the configuration-dependent position and orientation $\bm{x} (\bm{q})$ of the actual end-effector (``E'') frame $\ks{E}$.
In the following, the general, joint-independent, pose $\bm{x}$ of the robot end-effector is defined as the \emph{desired} (``D'') end-effector pose in the inverse kinematics problem and will be termed with ``$\bm{x}$'' without further supplements for the sake of compactness of the equations.
This general pose
%
\begin{equation}
\bm{x}
=
\begin{bmatrix}
\bm{x}_{\mathrm{t}}^\transp & \bm{x}_{\mathrm{r}}^\transp
\end{bmatrix}^\transp
\in {\mathbb{R}}^{6}
\label{equ:x_def}
\end{equation}
%
describes the desired robot end-effector frames $\ks{D}$ position
%
\begin{equation}
\bm{x}_{\mathrm{t}}
=
\ortvek{0}{r}{}{D}
\in {\mathbb{R}}^{3}
\label{equ:xt_def}
\end{equation}
%
and orientation
%\vspace{-0.5em}
%
\begin{equation}
\rotmat{0}{D} (\bm{x}_{\mathrm{r}})
=
\begin{bmatrix}\vek{n}{}{D} & \vek{o}{}{D} & \vek{a}{}{D}\end{bmatrix} \in \mathrm{SO(3)}
\label{equ:xr_def_rotmat}
\end{equation}
%
with respect to the base frame $\ks{0}$, which is marked with left subscript ``$(0)$'' for vectors and left superscript ``$0$'' for rotation matrices.
The rotation (\ref{equ:xr_def_rotmat}) is expressed without loss of generality with a set $\bm{\beta}$ of $X$-$Y$-$Z$-Euler angles
%\footnote{Other sets of Euler angles may be used as well.}
%
\begin{equation}
\bm{x}_{\mathrm{r}}
=
\begin{bmatrix}
\beta_1  & \beta_2 & \beta_3
\end{bmatrix}^{\mathrm{T}}
\in {\mathbb{R}}^{3},
\label{equ:xr_def}
\end{equation}
%
\begin{equation}
\bm{R}(\bm{\beta}) = \bm{R}_x(\beta_1) \bm{R}_y(\beta_2) \bm{R}_z(\beta_3) \in \mathrm{SO(3)}.
\label{equ:def_rmat_xyz}
\end{equation}
%
The deviation $\bm{\Phi}$ between the desired end-effector frame $\ks{D}$ expressed with $\bm{x}$ of (\ref{equ:x_def}) and the actual robots end-effector frame $\ks{E}$ expressed with $\bm{f}(\bm{q})$ of (\ref{equ:dirkin}) is defined as
%\vspace{-0.5em}
%
\begin{equation}
\bm{\Phi}=\begin{bmatrix}
\bm{\Phi}_{\mathrm{t}}^\transp & \bm{\Phi}_{\mathrm{r}}^\transp
\end{bmatrix}^\transp \in {\mathbb{R}}^{6},
\label{equ:Phi_def}
\end{equation}
%
which is the residual vector of the inverse kinematics problem.
The vector
%
\begin{equation}
\bm{\Phi}_{\mathrm{t}}(\bm{q},\bm{x})
=
- \ortvek{0}{r}{}{D} + \ortvek{0}{r}{}{E}(\bm{q})
=
- \bm{x}_{\mathrm{t}} + \ortvek{0}{r}{}{E}(\bm{q})
 \in {\mathbb{R}}^{3}
\label{equ:Phit_def}
\end{equation}
%
from the origins of $\ks{D}$ to $\ks{E}$ is the translational part and the rotational part
%
\begin{align}
\bm{\Phi}_{\mathrm{r}}(\bm{q},\bm{x})
= \begin{bmatrix}
\alpha_1  & \alpha_2 & \alpha_3
\end{bmatrix}^\transp
&=\bm{\alpha}\left(\rotmat{D}{E}(\bm{x}_{\mathrm{r}},\bm{q})\right)\nonumber \\
&=\bm{\alpha}\left(\rotmat{0}{D}^\transp (\bm{x}_{\mathrm{r}})\rotmat{0}{E}(\bm{q})\right) \in {\mathbb{R}}^{3}
\label{equ:Phir_def}
\end{align}
%
is also chosen as a set of Euler angles $\bm{\alpha}$ \cite{GoldenbergBenFen1985}, that is calculated from the rotation matrix in (\ref{equ:Phir_def}).
In the following, ``$\bm{\alpha}$'' will always refer to the rotation error/residual and ``$\bm{\beta}$'' to an orientation relative to the base frame.
The Euler angle convention of $\bm{\alpha}$ can be chosen independently of the choice for the orientation representation in  $\bm{\beta}$.
The intuitive approach of choosing
%
\begin{equation}
\bm{R}(\bm{\alpha}^*) := \bm{R}_x(\alpha_1^*) \bm{R}_y(\alpha_2^*) \bm{R}_z(\alpha_3^*) \in \mathrm{SO(3)}
\label{equ:alpha_convention_xyz}
\end{equation}
%
the same way as $\bm{\beta}$ leads to a set of transformations depicted in Fig.\,\ref{fig:frames_5dof_6dof}\,(a) where the intermediate steps of the single elementary rotations are omitted since they have no technical meaning.
The upperscript in $\bm{\alpha}^*$ in (\ref{equ:alpha_convention_xyz}) demarcates this specific example and following elaborations on the calculation of $\bm{\alpha}$.
%

\subsection{Effect of the Reciprocal Euler Angles}
\label{sec:RecEulAng_effect}

\begin{figure}[htb]
    \input{./figures/frame_comparison_combined_5dof_6dof.pdf_tex}
    \caption{Overview of the different frames (a) for 6-dof tasks with standard Euler angle notation and (b) for 5-dof tasks with reciprocal Euler angle notation.}
    \label{fig:frames_5dof_6dof}
\end{figure}

Using $\bm{\Phi}_{\mathrm{r}}{=}\bm{\alpha}^*$ as defined in (\ref{equ:alpha_convention_xyz}), all three components of $\bm{x}_{\mathrm{r}}{=}\bm{\beta}$ affect the rotation matrix $\rotmat{D}{E}$, which makes it impossible to remove one rotational coordinate from the kinematic description, even if it is not required in the task.
%
To encounter this issue, the Euler angle convention $\bm{\alpha}$ for the orientation error $\bm{\Phi}_{\mathrm{r}}$ is now chosen to be
\vspace{-0.1em}
%
\begin{equation}
\bm{R}(\bm{\alpha}) := \bm{R}_z(\alpha_1) \bm{R}_y(\alpha_2) \bm{R}_x(\alpha_3) \in \mathrm{SO(3)}
\label{equ:def_rmat_zyxr}
\end{equation}
%
instead of the definition from (\ref{equ:alpha_convention_xyz}).
This set of $Z$-$Y$-$X$-Euler angles $\bm{\alpha}$ is defined in this paper as being \emph{reciprocal} to the set of $X$-$Y$-$Z$-Euler angles of $\bm{\beta}$ for the absolute orientation.

The reciprocity refers to the switched order of the elementary axes $X$, $Y$ and $Z$ in the combination of the sets $\bm{\alpha}$ \emph{and} $\bm{\beta}$.
One set of Euler angles alone can not be declared as reciprocal without reference to another set of angles.
%
Similar to the six end-effector operational space coordinates $\bm{x}$, the task space of 3T2R tasks is defined to have five coordinates
%
\begin{equation}
\bm{\eta}
=
\begin{bmatrix}
\bm{\eta}_{\mathrm{t}}^\transp &
\bm{\eta}_{\mathrm{r}}^\transp
\end{bmatrix}^\transp
\in {\mathbb{R}}^{5}.
\end{equation}
%
The translational part
%\vspace{-0.5em}
%
\begin{equation}
\bm{\eta}_{\mathrm{t}}
=
\bm{x}_{\mathrm{t}}
=
\ortvek{0}{r}{}{D}
\in {\mathbb{R}}^{3}
\end{equation}
%
remains unchanged and the rotational part
%
\begin{equation}
\bm{\eta}_{\mathrm{r}}
=
\begin{bmatrix}
\beta_1  & \beta_2
\end{bmatrix}^\transp
=
\underbrace{\begin{bmatrix}
1 & 0 & 0  \\
0 & 1 & 0
\end{bmatrix}}_{=\bm{P}_{\eta}}
\bm{x}_{\mathrm{r}}
\in {\mathbb{R}}^{2}
\label{equ:etar_def}
\end{equation}
%
is modified compared to $\bm{x}$.
The last rotation $\beta_3$ around the $z$-axis $\bm{a}_{D}$ of $\rotmat{0}{D}$ is excluded from the task space by the selection matrix $\bm{P}_{\eta}$, since it corresponds to a rotation around the tool axis in 3T2R tasks and is a DoF of the operational space which can be set arbitrarily (from the kinematic point of view).

The frames $\ks{A1}$ and $\ks{A2}$ result from intermediate elementary rotations, as sketched in Fig.\,\ref{fig:frames_5dof_6dof}\,(b).
These intermediate frames are the partial frame rotation to the former 3T3R desired frame $\ks{D}$
%
\begin{equation}
\rotmat{0}{A1}
=
\bm{R}_x(\beta_1) \bm{R}_y(\beta_2)
=
\begin{bmatrix}
\vek{n}{}{A1} & \vek{o}{}{A1} & \vek{a}{}{A1}
\end{bmatrix}
\end{equation}
%
and the partial frame rotation
%
\begin{equation}
\rotmat{0}{A2}
=
\rotmat{0}{E}(\bm{q})
\left(\bm{R}_y(\alpha_2) \bm{R}_x(\alpha_3)\right)^\transp
=
\begin{bmatrix}
\vek{n}{}{A2} & \vek{o}{}{A2} & \vek{a}{}{A2}
\end{bmatrix}
\end{equation}
%
from the actual frame and the $x$- and $y$-axis error components.
%
The frames $\ks{A1}$, $\ks{A2}$ and $\ks{D}$ all share the same $z$-axis
%
\begin{equation}
\vek{a}{}{D}
=
\vek{a}{}{A1}
=
\vek{a}{}{A2}
\label{equ:z_axis_equal}
\end{equation}
%
which is also the tool axis, since transformations between these frames are only rotations $\bm{R}_z$ around the $z$-axes from (\ref{equ:z_axis_equal}).
\newpage
Since the tool axis rotation $\beta_3$ and the orientation error component $\alpha_1$ are defined around the same axis, $\beta_3$ only influences $\alpha_1$ and not $\alpha_2$ and $\alpha_3$, which can be expressed by
%
\begin{align}
\begin{bmatrix}
\alpha_1 \\
\alpha_2 \\
\alpha_3
\end{bmatrix}
=
\begin{bmatrix}
\alpha_1(\bm{q},\beta_1,\beta_2,\beta_3) \\
\alpha_2(\bm{q},\beta_1,\beta_2) \\
\alpha_3(\bm{q},\beta_1,\beta_2)
\end{bmatrix}
=
\begin{bmatrix}
\alpha_1(\bm{q},\bm{x}) \\
\alpha_2(\bm{q},\bm{\eta}) \\
\alpha_3(\bm{q},\bm{\eta})
\end{bmatrix}
\label{equ:alpha_dep_beta}.
\end{align}
%
This property of the reciprocal sets of Euler angles allows a kinematic description of robots in 3T2R tasks, as elaborated in the next sections.
It can be derived by symbolically comparing $\bm{\alpha}$ of (\ref{equ:alpha_def_rotmat_zyx}) for two different desired rotations $\bm{\beta}$ which only differ regarding a rotation $\beta_3$ around the tool axis.

\section{Application on the Inverse Kinematics of 3T2R Tasks}
\label{sec:RecEulAng_3T2R_app}

The standard methods, introduced in Sec.\,\ref{sec:Intro} for solving the inverse kinematics for 3T2R tasks and exploiting the functional redundancy, struggle with the definition of a Jacobian matrix with appropriate dimensions.

\subsection{Jacobian for Gradient-based Inverse Kinematics}

To obtain a Jacobian with minimal row dimension, the kinematic condition for the 3T2R problem in the coordinates $\bm{\eta}$ is now defined as
%
\begin{equation}
\bm{\Psi}=\begin{bmatrix}
\bm{\Psi}_{\mathrm{t}}^\transp & \bm{\Psi}_{\mathrm{r}}^\transp
\end{bmatrix}^\transp \in {\mathbb{R}}^{5}
\end{equation}
%
following the definition for $\bm{\Phi}$ from (\ref{equ:Phi_def}).
The translational part
%
\begin{equation}
\bm{\Psi}_{\mathrm{t}}(\bm{q},\bm{\eta})
=
\bm{\Phi}_{\mathrm{t}}(\bm{q},\bm{x})
=
- \bm{\eta}_{\mathrm{t}} + \ortvek{0}{r}{}{E}(\bm{q}) \in {\mathbb{R}}^{3}
\end{equation}
%
remains unchanged to (\ref{equ:Phit_def}).
The first component of the rotational part from (\ref{equ:Phir_def}) is omitted by the selection matrix $\bm{P}_{\Psi}$, since it corresponds to the orientation error $\alpha_1$ around the tool axis, leaving
%\vspace{-0.5em}
%
\begin{equation}
\bm{\Psi}_{\mathrm{r}}(\bm{q},\bm{\eta}) =
\begin{bmatrix}
\alpha_2  & \alpha_3
\end{bmatrix}^\transp
=
\overbrace{\begin{bmatrix}
    0 & 1 & 0  \\
    0 & 0 & 1
    \end{bmatrix}}^{=\bm{P}_{\Psi}}
 \bm{\Phi}_{\mathrm{r}} (\bm{q},\bm{x})
 \in {\mathbb{R}}^{2}.
\label{equ:Psir_def}
\end{equation}
%
The dependence on $\bm{\eta}$ and not on $\bm{x}$ can be explained by using (\ref{equ:alpha_dep_beta}) and (\ref{equ:etar_def}) together with $\rotmat{A1}{A2}=\bm{R}_z(\beta_3+\alpha_1)$ from Fig.\,\ref{fig:frames_5dof_6dof}\,(b) which results to
%
\begin{align}
\bm{\Psi}_{\mathrm{r}}(\bm{q},\bm{\eta})
&=
\bm{P}_{\Psi} \bm{\alpha}\left(\rotmat{A2}{E}(\bm{q},\bm{\eta}_{\mathrm{r}},\alpha_1,\beta_3)\right) \nonumber\\
&=
\bm{P}_{\Psi} \bm{\alpha}\left(\rotmat{0}{A1}^\transp (\bm{\eta}_{\mathrm{r}})\rotmat{0}{E}(\bm{q})\right).
\end{align}

The condition $\bm{\Phi}=\bm{0}$ or $\bm{\Psi}=\bm{0}$ leads to a valid configuration of the end-effector position and the complete orientation of the end-effector (using $\bm{\Phi}$) or the orientation only of the tool-axis (using $\bm{\Psi}$).

Following \cite{GoldenbergBenFen1985}, the inverse kinematics problem for serial link robots in 6-DoF tasks at the iterative step $k+1$ can be derived with the linear approximation of the Taylor series expansion of $\bm{\Phi}(\bm{q},\bm{x})$ to
%
\begin{equation}
\bm{\Phi}(\bm{q}^{k+1},\bm{x}) =
\bm{\Phi}(\bm{q}^{k},\bm{x})
+
\frac{\partial}{\partial \bm{q}} \bm{\Phi}(\bm{q},\bm{x}) \biggr\rvert_{\bm{q}^k} (\bm{q}^{k+1} - \bm{q}^k)
\label{equ:taylor_phi}
\end{equation}
%
where $\bm{\Phi}_{\partial\bm{q}}=(\partial \bm{\Phi} / \partial \bm{q})$ is called the ``Jacobian matrix corresponding to the residual vector'' ($\bm{\Phi}$) in \cite{GoldenbergBenFen1985} and $\bm{q}^0$ is assumed as given.
%
For 3T2R tasks
%
\begin{equation}
\bm{\Psi}(\bm{q}^{k+1},\bm{\eta}) =
\bm{\Psi}(\bm{q}^{k},\bm{\eta})
+
\frac{\partial}{\partial \bm{q}} \bm{\Psi}(\bm{q},\bm{\eta}) \biggr\rvert_{\bm{q}^k} (\bm{q}^{k+1} - \bm{q}^k)
\label{equ:taylor_psi}
\end{equation}
%
can be defined in the same way with the condition
%
\begin{equation}
\bm{\Psi}(\bm{q}^{k+1},\bm{\eta})=\bm{0}
\end{equation}
%
for solution of the inverse kinematics in the next step $k+1$. The increment
%
\begin{equation}
\Delta \bm{q}^k
=
(\bm{q}^{k+1} - \bm{q}^k)
=
\left(\frac{\partial \bm{\Psi}(\bm{q},\bm{\eta})}{\partial \bm{q}}\biggr\rvert_{\bm{q}^k}\right)^{\dagger}
(\bm{0} - \bm{\Psi}(\bm{q}^{k},\bm{\eta}))
\label{equ:deltaq_psi}
\end{equation}
%
of the joint angles towards this solution can be used in iterative algorithms like Newton-Raphson together with methods to adapt the step sizes to ensure convergence.
Depending on the dimension of the matrix, $(\cdot)^\dagger$ denotes the matrix inverse or the pseudo-inverse.

\subsection{Discussion of Singularities}

In \cite{Zlajpah2017}, quaternions were used in favor of Euler angles for the orientation error with the reasons that a singularity-free representation of $\bm{\Phi}=\bm{0}$ is needed.
This is the case for Tait-Bryan angles\footnote{Tait-Bryan angles are referred to as $A$-$B$-$C$-Euler angles with axes $A \ne C$ as opposed to ``proper Euler angles'' with $A = C$. The elementary axes are $A,B,C \in \{ X,Y,Z\}$.} like e.\,g. the $Z$-$Y$-$X$ notation used here for $\bm{\alpha}$.
For control purposes it can be assumed that the components of the orientation error $\bm{\alpha}$ always stay below $\pm$90$^\circ$, which avoids the ``gimbal lock'' representation singularity of Euler angles.
This assumption can be justified by the consideration that active and effective position and orientation tracking will only produce small errors.
A singularity-free representation of the absolute orientation $\bm{\beta}$ has to be ensured at the phase of motion planning, as well as avoiding discontinuities of the trajectory.

\subsection{Remarks on Differentiation and Rotation Matrices}
\label{sec:RecEulAng_implement}

The Jacobians $\bm{\Phi}_{\partial\bm{q}}$ of (\ref{equ:taylor_phi}) or $\bm{\Psi}_{\partial\bm{q}}$ of (\ref{equ:taylor_psi}) consist of nested non-linear functions and do not use the geometric Jacobian of the serial link manipulator for the rotational part, which is easy to calculate.

However, $\bm{\Phi}_{\partial\bm{q}}$ can be implemented efficiently by exploiting the chain rule and sparsity of the matrices with partial derivatives as shown in the following.

The column operator $\overline{\bm{R}}$ for rotation matrices $\bm{R}$ to stack the coordinate systems unit vectors $\bm{n},\bm{o},\bm{a} \in {\mathbb{R}}^{3}$ vertically instead of horizontally is defined as
%
\begin{equation}
\overline{\bm{R}}(\bm{R})=\begin{bmatrix}
\bm{n} \\ \bm{o} \\ \bm{a}
\end{bmatrix} \in {\mathbb{R}}^{9}
\quad
\mathrm{with}
\quad
\bm{R}=\begin{bmatrix}
\bm{n} & \bm{o} & \bm{a}
\end{bmatrix}
=
\begin{bmatrix}
{n_x}&{o_x}&{a_x} \\
{n_y}&{o_y}&{a_y} \\
{n_z}&{o_z}&{a_z} \\
\end{bmatrix}
 \in \mathrm{SO}(3)
\label{equ:def_rotmat}
\end{equation}
%
to avoid differentiating matrices or w.r.t. matrices.
Matrix multiplication is then expressed with the matrix product operator $\overline{\Pi}$
%
such that
%
\begin{equation}
\rotmato{1}{3}
=
\overline{\prod}\left( \rotmato{1}{2}, \rotmato{2}{3}\right)
=
\overline{\bm{R}}(\rotmat{1}{3})
\quad
\mathrm{with}
\quad
\rotmat{1}{3}
=
\rotmat{1}{2}
\rotmat{2}{3}.
\label{equ:matprod}
\end{equation}
%
The transposition operator $\bm{P}_\transp$ is a $9 \times 9$ permutation matrix such that
%
\begin{equation}
\rotmato{2}{1}
=
\bm{P}_\transp \rotmato{1}{2}
\in {\mathbb{R}}^{9}
\enspace
\mathrm{with}
\enspace
\rotmat{2}{1}
=
\rotmat{1}{2}^\transp
\in \mathrm{SO}(3)
\enspace
\mathrm{and}
\enspace
\rotmato{1}{2}=\overline{\bm{R}}(\rotmat{1}{2})
.
\end{equation}
%
The Euler angles can be calculated from the general rotation matrix $\bm{R}$ of (\ref{equ:def_rotmat}) in the same way as before\footnote{Utilizing the sign-aware operator $\arctantwo(y,x)$ instead of $\arctan(y/x)$ allows angles to be in $(-\pi,+\pi]$, removes ambiguities and provides global differentiability.} using these operators with the notation
%
\begin{equation}
\bm{\alpha}(\overline{\bm{R}})
=
\bm{\alpha}(\bm{R})
=
\begin{bmatrix}
\arctantwo \left( {n_y} , { n_x} \right) \\
\arctantwo \left( -{n_z} , \sqrt {{{a_z}}^{2}+{{ o_z}}^{2}} \right) \\
\arctantwo \left( {o_z} , {a_z} \right)
\end{bmatrix}
\label{equ:alpha_def_rotmat_zyx}
\end{equation}
%
at the $Z$-$Y$-$X$ example.
Finally, applying this to the rotational part of the residual vector Jacobian and using the chain rule for differentiation yields
%
\begin{align}
\frac{\partial}{\partial \bm{q}}\bm{\Phi}_{\mathrm{r}}
&=
\frac{\partial}{\partial \bm{q}} \bm{\alpha}\left(\rotmat{0}{D}^\transp(\bm{x}) \rotmat{0}{E}(\bm{q})\right) \label{equ:grad_Phi_q}\\
&=
\frac{\partial}{\partial \bm{q}} \bm{\alpha}\left(\overline{\prod}\left( \rotmato{0}{D}^\transp(\bm{x}), \rotmato{0}{E}(\bm{q})\right)\right) \nonumber \\
&=
%underbrace für Geschweifte Klammern drunter, vphantom nur für vertikale Größe des mittleren Terms
\underbrace{\vphantom{\left(\frac{\partial \overline{\prod}\left(\rotmato{0}{D}^\transp, \rotmato{0}{E}\right)}{\partial \rotmato{0}{E}}\right)}\left(\frac{\partial \bm{\alpha}}{\partial \overline{\bm{R}}}\right)}_{\mathrm{I} \in {\mathbb{R}}^{3 \times 9}}
\underbrace{\left(\frac{\partial \overline{\prod}\left(\rotmato{0}{D}^\transp, \rotmato{0}{E}\right)}{\partial \rotmato{0}{E}}\right)}_{\mathrm{II} \in {\mathbb{R}}^{9 \times 9}}
\underbrace{\vphantom{\left(\frac{\partial \overline{\prod}\left(\rotmato{0}{D}^\transp, \rotmato{0}{E}\right)}{\partial \rotmato{0}{E}}\right)}\left(\frac{\partial \rotmato{0}{E}(\bm{q})}{\partial \bm{q}} \right)}_{\mathrm{III} \in {\mathbb{R}}^{9 \times \mathrm{dim}(\bm{q})}}.  \nonumber
\end{align}
%
The first two partial derivatives ``I'' and ``II'' from (\ref{equ:grad_Phi_q}) are sparse matrices of low complexity where the elements of $\rotmat{D}{E}$ and $\rotmat{0}{D}$ have to be inserted.
The last partial derivative ``III'' can be derived efficiently with computer algebra systems.

The translational part $\bm{\Phi}_{\mathrm{t},\partial\bm{q}}=\partial \bm{\Phi}_{\mathrm{t}} / \partial \bm{q}=\bm{\Psi}_{\mathrm{t},\partial\bm{q}}$ is enclosed in the geometric Jacobian of the manipulator and is not considered at this point to focus on the rotational aspects.
The gradient
$\bm{\Psi}_{\mathrm{r}, \partial\bm{q}}=\partial \bm{\Psi}_{\mathrm{r}} / \partial \bm{q}=\bm{P}_{\Psi}\bm{\Phi}_{\mathrm{r},\partial\bm{q}}$
is obtained from the results of (\ref{equ:grad_Phi_q}) with the selection matrix $\bm{P}_{\Psi}$ from (\ref{equ:Psir_def}).

To account for exchangeable end-effectors or tools, a distinguished frame rotation $\rotmat{0}{N}(\bm{q})$ to the last robot link frame and a constant frame rotation $\rotmat{N}{E}$ to the end-effector frame can be used.
The properties of the column-operator allow then to substitute the last term ``III'' in (\ref{equ:grad_Phi_q}) with
%
\begin{align}
\frac{\partial \rotmato{0}{E}(\bm{q})}{\partial \bm{q}}
&=
\frac{\partial}{\partial \bm{q}} \overline{\prod}\left( \rotmato{0}{N}(\bm{q}), \rotmato{N}{E}\right) \label{equ:ee_rotation_gradq}\\
&=
\left(\frac{\partial}{\partial \rotmato{0}{N}} \overline{\prod}\left( \rotmato{0}{N}, \rotmato{N}{E}\right)\right)
\left(\frac{\partial}{\partial \bm{q}} \rotmato{0}{N}(\bm{q})\right). \nonumber
\end{align}
%
%The gradient ``I'' in (\ref{equ:ee_rotation_gradq}) matrix with linear entries where $\rotmat{N}{E}$ can be inserted directly similar to ``II'' in (\ref{equ:grad_Phi_q}).

\section{Resolving Functional Redundancy for 3T2R Tasks}
\label{sec:ResFuncRed}

%with $\mathrm{dim}(\bm{\Psi})=5$

The inverse kinematics formalism (\ref{equ:deltaq_psi}), described in the previous section \ref{sec:RecEulAng_3T2R_app}, does not take into account the functional redundancy yet.

The typical scenario for 3T2R tasks in industry is a serial link robot with $\mathrm{dim}(\bm{q})>5$.
Most commonly a classical industrial robot with $\mathrm{dim}(\bm{q})=6$ will be used.
Since $\mathrm{dim}(\bm{\Psi})=5$, at least one DoF is free for optimization of additional criteria.

For the sake of simplicity, as an additional criterion the summed $\bm{W}$-weighted quadratic distances
\vspace{-0.1em}
%
\begin{equation}
h(\bm{q})
=
\frac{1}{2} (\bm{q}-\bar{\bm{q}})^\transp\bm{W}(\bm{q}-\bar{\bm{q}})
\end{equation}
%
of the joint positions $\bm{q}$ from their respective reference position $\bar{\bm{q}}$ will be used.
Minimizing $h(\bm{q})$ avoids the risk of joints reaching their technical limits.
The gradient
\vspace{-0.1em}
%
\begin{equation}
h_{\partial\bm{q}}
=
\frac{\partial h}{\partial \bm{q}}
=
\bm{W}(\bm{q}-\bar{\bm{q}})
\end{equation}
%
can be used to include this additional minimization into the solution of the inverse kinematics.
The gradient $h_{\partial\bm{q}}$ is projected into the nullspace of $\bm{\Psi}_{\partial\bm{q}}$ with
\vspace{-0.1em}
%
\begin{align}
{\Delta}\bm{q}
&=
{\Delta}\bm{q}_{\mathrm{T}} + {\Delta}\bm{q}_{\mathrm{N}} \nonumber \\
&=
\bm{\Psi}_{\partial\bm{q}}^{\dagger} (-\bm{\Psi}) +  (\bm{1}-\bm{\Psi}_{\partial\bm{q}}^{\dagger}\bm{\Psi}_{\partial\bm{q}}) h_{\partial\bm{q}}
\label{equ:nullspace}
\end{align}
%
where the nullspace incremental motion ${\Delta}\bm{q}_{\mathrm{N}}$ does not affect the task achievement ensured via ${\Delta}\bm{q}_{\mathrm{T}}$ \cite{Yoshikawa1984}.

It is reported in \cite{GuoDonKe2015} that their optimization does not work for industrial robots where the tool axis is aligned parallel to the last robot joint axis.
This ``pointing configuration'' can also not be addressed by the nullspace projection from (\ref{equ:nullspace}), since the nullspace corresponds to the last robot axis and (in the case of a six-DoF robot)
\vspace{-0.1em}
%
\begin{equation}
\bm{1}-\bm{\Psi}_{\partial\bm{q}}^{\dagger}\bm{\Psi}_{\partial\bm{q}}
=
\begin{bmatrix}
\bm{0}_{5 \times 5} & \bm{0}_{5 \times 1} \\
\bm{0}_{1 \times 5} & 1_{1 \times 1}
\end{bmatrix}
\end{equation}
%
only projects the gradient $h_{\partial\bm{q}}$ of additional criteria onto the last joint.
Therefore, the method does only work if the tool is mounted in a different configuration (``side'' or ``hanging'' in \cite{GuoDonKe2015}), which might be unfavorable for some end-effectors or tasks.

\section{Conclusions}
\label{sec:Conclusion}
\vspace{-0.2em}
This paper presented a novel concept to formulate the inverse kinematics problem of serial kinematic chains using reciprocal sets of Euler angles.
This exploits the properties of Euler angles to reduce the number of coordinates required for 3T2R tasks which are of high industrial relevance.
Applications to the inverse kinematics of serial robots are given.
%The detailed view on the practical implementation aims at facilitating the understanding of the approach and at reducing the barrier for potential users.
%
Future works will include comparative simulative evaluation against state of the art methods, inquiries on singularities and the relation to the geometric Jacobian and the application to parallel robots.

\section*{Acknowledgements}
\vspace{-0.2em}
The financial support from the Deutsche Forschungsgemeinschaft (DFG) under grant number OR 196/33-1 is gracefully acknowledged.
\vspace{-0.2em}

% BIBLIOGRAPHY
\bibliographystyle{spmpsci_unsrt}
\bibliography{ikfr_ref}

\end{document}


\chapter{Conclusion}
\label{chap:conclusion}

% What we did and what others did
We have formalised multi-tape Turing machines in Coq.  We developed a framework for programming and proving correctness and time complexity of
multi-tape Turing machines.  We have demonstrated the power of this framework by implementing and verifying a multi-tape Turing machine that simulates
an abstract machine.  This machine is a variation of the heap machine in Kunze et~al.~\cite{KunzeEtAl:2018:Formal}.  The two variants differ in that
programs in our version are linearised lists of commands.  In~\cite{KunzeEtAl:2018:Formal}, the authors show that their heap machines can simulate
terms of the programming language $L$, which is a subset of the call-by-value $\lambda$-calculus.  It should be easy to formalise the reduction from
the heap machine in~\cite{KunzeEtAl:2018:Formal} to our version.  By that, we would formalise the reduction from the halting problem of $L$ to the
halting problem of multi-tape Turing machines.  This is, however, beyond the scope of this thesis.  It is an ongoing research
project~\cite{ForsterLOLA2018}, to implement a Coq library of undecidability reductions, and this thesis provides one step towards this goal.  The
reduction from the halting problem of single-tape Turing machines to the Post correspondence problem (PCP) has already been mechanised in Coq
in~\cite{forster2018verification}.

\paragraph{Differences to other mechanisations of Turing machines}
We build on Asperti and Ricciotti`s framework from~\cite{asperti2015} inside the theorem prover Matita, and initially ported their definitions of
tapes and Turing machines to Coq.  We find their inductive definition of tapes appealing, because of its symmetric and finite nature.  Because of the
symmetric nature of their definition of tapes, it was easy to define an operator $\MS{Mirror}$ that mirrors the transition function of a machine.
This is in contrast to the implementation of tapes in~\cite{xu2013}, where tapes are split into two halves, and the right half contains the current
symbol.  The finite nature made it possible to define an always terminating machine that moves the head to the right (or using $\MS{Mirror}$ to the
left) end of the tape.  This is in contrast to~\cite{ciaffaglione2016}, where tapes are implemented as infinite streams of symbols.  Our framework
implements five major improvements on~\cite{asperti2015}.  (1) By introducing labelled machines we make it unnecessary to reason about concrete states
of machines.  The authors in~\cite{asperti2015} already note that reasoning about internal states is tedious and therefore do not include the
terminating state in their definition of realisation.  However, they also need a separate definition of realisation that includes the terminating
state.  (2) We have introduced a notion of time complexity that relates the inputs to the number of steps needed for the computation.  (3) By
introducing an operator $\Switch$ that generalises sequential composition and conditional, we simplified the verification of both operators and also
introduced a useful operator that was used throughout the thesis.  (4) We implemented general lifting operators that make it possible to compose small
machines (w.r.t.\ the alphabet and number of tapes) to fairly complex machines.  At this point, composing compound machines is reasonably easy, but we
(5) have introduced another layer of abstraction.  We have made it possible to directly manipulate values of encodable types.

% Norrish`s comment about the "daunting prospect".
In~\cite{norrish2011mechanised}, Norrish concludes that:
\begin{quote}
  If register machines are unappealing because of their general fiddliness, Turing machines are an even more daunting prospect.
\end{quote}
Certainly, Turing machines are not appealing.  We have spent considerable efforts (ca.\ one year) to make programming and verifying Turing machines
feasible.  Interestingly, we ended up at a point, where programming and verifying Turing machines can be (in some sense) \textit{easier} than for
register machines, because register machines are restricted to natural numbers.  The on-paper design, implementation and verification of the simulator
was finished in three weeks.

\paragraph{Duality of realisation and termination}
We noted that our concepts for correctness and time complexity are dual in a sense.  The (weak) notion of realisation says that \textit{if} the
machine terminates, then the output is correct w.r.t.\ a correctness relation $R$.  On the other side, a machine terminates in a termination relation
$T$, if for all pairs of input tapes $t$ and step numbers $k$ that are in $T$, the machine terminates in $k$ steps given the input $t$.  Realisation
is monotone (cf.\ Lemma~\ref{lem:Realise_monotone}), and termination is anti-monotone (cf.\ Lemma~\ref{lem:TerminatesIn_monotone}).  We find it
remarkable that we use an inductive correctness relation for $\MS{While}$ (cf.~Lemma~\ref{lem:While_Realise}) and a co-inductive running time relation
(cf.\ Lemma~\ref{lem:While_TerminatesIn}).

\paragraph{Similarity of realisation and Hoare logic}
As already noted in~\cite{ciaffaglione2016}, the notion of realisation is similar to Hoare logic, that is widely used for program verification.  For
example, consider the Hoare proof rule for sequential composition and the corresponding relational rule (for unlabelled machines
$M_1,M_2 : \TM_\Sigma^n$):
\[
  \inferrule{\{A\}~P_1~\{B\} \and \{B\}~P_2~\{C\}}{\{A\}~P_1 \Seq P_2~\{C\}}
  \qquad
  \inferrule{M_1 \Realise R_1 \and M_2 \Realise R_2}{M_1 \Seq M_2 \Realise R_1 \circ R_2}
\]
Sequential composition of machines amounts to relational composition of correctness relations (cf.\ Lemma~\ref{lem:Seq_RealiseIn}).  We encode
preconditions and postconditions inside correctness relations.  This means that if the precondition does not hold for input tapes $t$, this implies
$R~t~(l,t')$.  We are not aware of a Hoare-style calculus for reasoning about termination in a concrete number of steps related to the input, that is
dual to Hoare logic, like in our duality between realisation and termination.

\paragraph{Problems of the framework}
The biggest problem of this framework is that encodability of types can be ambiguous.  For example, there are more than three ways how to encode
natural numbers on the alphabet of the heap machine simulator (cf.~Section~\ref{sec:Lookup}).  We had to mentally keep track of in which encoding a
value is encoded on a tape, and to translate values from one encoding to another.  The greatest part of the total compilation time (which is less then
5~minutes) consists of rewriting tapes.  This could probably be further optimised.

\paragraph{Comparison of proof assistants}
Asperti and Ricciotti~\cite{asperti2015} propose the formalisation of Turing machines as a benchmark for comparing proof assistants.  We think that
the formalisation and usability of finite sets could be a benchmark for itself.  However, the task ``formalise Turing machines in proof assistant
$X$'' is rather broad.  There are many mathematical formalisations of Turing machines, and some might be easier to implement in one or the other proof
assistant.  For example, Isabelle does not support dependent types, so this concrete formalisation of Turing machines in this thesis would not be
possible in Isabelle.  Dependent types are quite central in our formalisation of Turing machines.  For example, defining $\Switch$ without them would
probably be considerable harder.

\paragraph{Future work}

\enlargethispage{0.5cm}

When we defined the notion of value-containment (cf.~Section~\ref{sec:value-containment}), we had future work in mind where we formalise space-usage
of machines.  We were careful to avoid memory-leaks in the machines, but have not yet formalised this aspect of correctness.  We can strengthen the
correctness relations with commitments about the space-usage of each tape.  Asperti and Ricciotti`s inductive definition of tapes is very helpful in
this regard, because their tapes never decrease the number of symbols.  This means that the total space usage of a tape is just the number of symbols
on the tape.  Our idea is that we parametrise the definition of value-containment over the length $l$ of the ``rest list'' on the left, and write
$t \simeq_{l} x$.  Note that, by definition, there are no symbols beyond the stop symbol on the right side of the tape, so the total size of the tape
only depends on the length of the encoding and the length of the left rest.  For example, $\MS{CaseNat}$ does not change the amount of totally
allocated symbols, but decreases the length of the encoding and increases the length of the rest by one.  On the other side, $\MS{ConstrS}$
``consumes'' one rest symbol, i.e.\ it decreases the length of the rest by one and increases the length of the encoding by one.  Thus, if the rest is
empty, $\MS{ConstrS}$ allocates one new symbol.

%\newpage

Further future work could be to show that the running time function of the simulator is polynomial w.r.t.\ the number of steps and the length of the
encoding of the initial heap machine state, see~\cite{ForsterLOLA2017}.  We could also formalise the reduction from multi-tape Turing machines to
single-tape Turing machines, and from single-tape Turing machines to single-tape Turing machines with a binary alphabet.  The framework can be used to
program other simulator machines, for example, for the ``naive'' substitution-based machine in~\cite{KunzeEtAl:2018:Formal}.  We could implement a
universal Turing machines as in~\cite{asperti2015}, and formalise results of computationally and complexity theory, for example the undecidability of
the halting problem and Rice`s theorem.  The opposite reduction from multi-tape Turing machines to $L$, i.e.\ programming an $L$ expression that
simulates multi-tape Turing machines, is also open for future work.  This should be a ``less daunting prospect'', because there is a framework for
verified extraction of Coq terms to expressions of $L$, see~\cite{forster2016verified}.

%%% Local Variables:
%%% TeX-master: "thesis"
%%% End:


\subsection{Motivation, Landscape and Current Problem}

    As computer processor clock speeds have begun to stagnate in frequency increases per year, manufacturers have begun to shift focus to multiple cores in search of greater performance.
    Supercomputers for decades have operated around the idea of clusters and massive parallelism.
    As such, there is now more than ever a need to study the effects of parallelism in computation and to be able to effectively model concurrent communicating systems as they start to become commonplace in all computational applications.

\subsection{Scope and Relevance of Research}

    The following aims to provide a visualisation of the parallel computation of multiple processes within the context of a concurrency calculus.
    This will be divided into several modular parts that apart demonstrate some challenges on successful implementation, but together form what should prove to be a useful proof-of-concept tool to aid in understanding of calculi of communicating processes.\\

    In particular, the project tackles the details of implementation of a computational calculus of communicating mobile processes.
    This implementation is then further extended to provide an interactive visualisation of computations to aid in the understanding of how such calculi operate.
    As discussed later in~\ref{subsec:pi-calculus}, the project aims to provide an improvement over the $\pi$-calculus described by~\cite{pi-calculus}, while still remaining functionally equivalent and equally expressive.

\subsection{Project Aims}

    The project seeks to provide an implementation of both the Solo Calculus described by~\cite{solo-calculus}, for which there exists an encoding of the $\pi$-calculus within itself, and also of Solo Diagrams described by~\cite{solo-diagrams}, an intuitively graphical representation of the calculus.
    These diagrams can then aid in understanding of reductions of process calculi, while maintaining a clean and simple language with strong, provable properties.
    Furthermore, the design of the Solo Calculus is such that it is fully asynchronous.
    That is, unlike in the $\pi$-calculus where processes ‘block’ while waiting for inputs/outputs, it is shown through the construction of the Solo Calculus that no such system is required --- however there still exists a way of building such a system to give the effects of the $\pi$-calculus should it be desired.
    For these reasons, the Solo Calculus is found to be an interesting alternative to the more common $\pi$-calculus.

\subsection{Overview of Dissertation Structure}

    The first section details an in-depth review of the surrounding literature and current state of the art.
    This includes an examination of various computational calculi, both concurrent and not, and an evaluation of their effectiveness for their given use-cases.
    Included also are some short examples to give a feel of how each calculus is used.\\

    Afterwards follows a short project requirements specification and investigation on technologies planned to be used in this project and justifications as to why each was chosen.\\

    Following that is then a breakdown of the development process, description of some simple algorithms involved and the pitfalls which may not be immediately obvious.
    This section attempts to show both the initial and final forms of the project and what difficulties caused this evolution.\\

    Finally, there is a short conclusion on the effectiveness of the design choices made and how a similar project could be conducted differently.\\


\section{Price response functions}\label{sec:response_functions}

In Sect. \ref{subsec:response_function_trade} we analyze the responses
functions in trade time scale and in Sect.
\ref{subsec:response_function_physical} we analyze the responses functions in
physical time scale.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Response functions on trade time scale}
\label{subsec:response_function_trade}

The price response function in trade time scale is defined as
\cite{my_paper_response_financial}
\begin{equation}\label{eq:response_functions_trade_scale_general}
    R^{\left(\textrm{t}\right)}_{i}\left(\tau\right)=\left\langle
    r^{\left(\textrm{t}\right)}_{i}\left(t-1,\tau \right)
    \varepsilon_{i}^{\left(\textrm{t}\right)}
    \left(t, n\right)\right\rangle _{T}.
\end{equation}
To compute the response functions on trade time scale, we use both, the trade
signs and the returns from the tick-by-tick original data during a week in
market time. Then, the response is averaged by the number of trades.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=\columnwidth]
    {figures/04_responses_trade_scale.png}
    \caption{Price response functions
             $R^{\left(\textrm{t}\right)}_{i}\left(\tau\right)$ versus time
             lag $\tau$ on a logarithmic scale in trade time scale for the
             years 2008 (top), 2014 (middle) and 2019 (bottom).}
    \label{fig:response_function_trade_scale}
\end{figure}

The results of Fig. \ref{fig:response_function_trade_scale} show the
price response functions of the seven foreign exchange major pairs used in the
analysis (see Table \ref{tab:majors}) for three different years. The results
found for all the years are entirely in line with price responses seen in other
financial markets, particularly with correlated financial markets. The response
functions have an initial increasing trend to a maximum, that flattens out and
saturates at some level, and eventually slowly decrease. This shape is
explained by an initial increase caused by autocorrelated transaction flow. The
flattening out is due to the market liquidity adapting to this flow and
assuring diffusive prices \cite{EMH_lillo}. For our selected pairs, a time lag
of $\tau = 10^{3} $ trades is enough to see an increase to a maximum followed
by a decrease. Thus, the trend in the price response functions is eventually
reversed. The response signal is much more noisier in the year 2008 for the
first seconds in the time lag. This behavior is because of the smaller amount
of data of the corresponding year. In general, more data was recorded in recent
years than in past years. In the three years analyzed, the more liquid currency
pairs have a smaller response in comparison with the non-liquid pairs.  The
strength of the response function varies from one year to the other. In 2008
the strength of the signal was one order of magnitude stronger than the
response in 2014, but the signals in 2014 have approximately twice the strength
of the signals of 2019. This behavior can be explained by the fact that in
recent times algorithm trading has been used intensively. Thus, many more
trades were carried out in the last years, which means, the impact of each
trade is reduced, and then the response functions tend to decrease compared
with previous years.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Response functions on physical time scale}
\label{subsec:response_function_physical}

One important detail to compute the price response function on physical time
scale is to define how the averaging of the function will be made, because the
response functions highly differ when we include or exclude
$\varepsilon^{\left(\textrm{p}\right)}_j \left( t\right) = 0$
\cite{Wang_2016_cross}. The price responses including
$\varepsilon^{\left(\textrm{p}\right)}_j \left( t\right) = 0$ are weaker than
the excluding ones due to the omission of direct influence of the lack of
trades. However, either including or excluding
$\varepsilon^{\left(\textrm{p}\right)}_j \left( t\right) = 0$ does not change
the trend of price reversion versus the time lag, but it does affect the
response function strength \cite{Wang_2016_avg}. For a deeper analysis of the
influence of the term
$\varepsilon^{\left(\textrm{p}\right)}_j \left( t\right) = 0$ in price response
functions, we suggest reviewing Refs. \cite{Wang_2016_avg,Wang_2016_cross}. We
will only take into account the price response functions excluding
$\varepsilon^{\textrm{p}}_j \left( t\right) = 0$.

We define the price response functions on physical time scale, using
the trade signs and the returns sampled in seconds from the original data on
physical time scale. The price response function on physical time scale is
defined as \cite{my_paper_response_financial}
\begin{equation}\label{eq:response_functions_time_scale_general}
    R^{\left(\textrm{p}\right)}_{i}\left(\tau\right)=\left\langle
    r^{\left(\textrm{p}\right)}_{i}\left(t-1, \tau\right)
    \varepsilon_{i}^{\left(\textrm{p}\right)} \left(t\right)\right\rangle _{P}
\end{equation}
\begin{figure}[htbp]
    \centering
    \includegraphics[width=\columnwidth]
    {figures/04_responses_physical_scale.png}
    \caption{Price response functions
             $R^{\left(\textrm{p}\right)}_{i}\left(\tau\right)$ excluding
             $\varepsilon^{\left(\textrm{p}\right)}_{i}\left(t\right) = 0$
             versus time lag $\tau$ on a logarithmic scale in physical time
             scale for the years 2008 (top), 2014 (middle) and 2019 (bottom).}
    \label{fig:response_function_physical_scale}
\end{figure}
The results shown in Fig. \ref{fig:response_function_physical_scale} are the
price response functions on physical time scale for three different years. The
results show approximately the same behavior observed in currency exchange
pairs in trade time scale, and in correlated financial markets, where we can
see that an increase to a maximum is followed by a decrease. Thus again, the
trend in the price responses is eventually reversed. An exception occurs in the
year 2008, where the response at short time lags seems to decrease, to then
start to slightly increase, and finally it decreases again.

The price response functions on physical time scale are smoother than the
responses on trade time scale. As we reduce from trade data all the returns and
trade signs in one second to one data point on physical time scale, and as this
sampling gives the same weight to every data point, the curves look smoother.

Compared with the response functions on trade time scale, the strength of the
signal of the response functions on physical time scale are similar in
magnitude in the corresponding years. Thus, the strength of the signal in 2008
for trade time scale is similar to the strength of the signal in 2008 for
physical time scale, and so on. This behavior is different from the one
presented in correlated financial markets, where the results differ about a
factor of two depending on the time scale \cite{my_paper_response_financial}.

On physical time scale, we can see that the liquid pairs have a smaller price
response compared with non-liquid pairs. The liquidity of the pairs vary
regarding the analyzed year. For the years 2008 and 2014, the most liquid pairs
are the EUR/USD and the GBP/USD. For 2019 the most liquid pairs are EUR/USD and
USD/CAD. Therefore, the price response of a foreign exchange pair with large
activity is smaller to the small impact of each trade. Also, the former year
responses have stronger signals. We consider the same argument of algorithm
trading to explain why the signals in recent years are weaker than in older
years.


\section{Introduction}

This section describes the problem that we tackle in this thesis (i.e., large-scale patterns prediction over multiple input event streams), followed by a brief overview of our proposed approach.

%For later  an introdcution/motavation  section should be added here %
\subsection{Problem Formulation}
%refine the stream and event pattern %
%define the pattern we deal formally%
% include base line 1 batch size in experemintal results%

Given a set of $K$ real-time streams of events $S = \{ s_1,s_2, ..., s_k\}$ as input, which are associated with a set of $K$  objects $O = \{ o_1, ..., o_k\}$. Where each stream $s_i=\langle e_1,e_3...,e_t,...\rangle$  is a time-ordered sequence of events, these events are connected to a single reference object $o_i \in O$,  $e_t$  refers to the current time event within the unbounded stream, we give the definition of the input event sample as follows:
\begin{definition}
Each event is defined as a tuple of attributes $e_i = (type,\tau,a_1,a_2.....,a_n,id)$:  where $type$ is the event type attribute that takes a value from a set of finite event types/symbols $\Sigma$, $\tau$ represents the timestamp of the event tuple,  the  $a_1,a_2,...,a_n$ are spatial or other contextual features (e.g., speed), these features are varying from one application to another, while the $id$ attribute connects the event tuple to the associated domain object.
\end{definition}

A user-defined pattern $\mathcal{P}$ is given in the form of a sequence of event types, while the main goal is to provide predictions about the full matches of $\mathcal{P}$ within each event stream $s_i\in S$ in real-time.

\par The setting that is considered in this thesis is described in the following:\\
  A large-scale patterns prediction over multiple input event streams system that  consists of $K=\left\vert{S}\right\vert=\left\vert{O}\right\vert$ distributed predictor nodes $n_1,n_2...,n_k$, each of which consumes an input event stream $s_i\in S$ and provide an online predication service. Each node $i \in [K]$ consumes a single event stream $s_i$ associated with a single object $o_i \in O$, in addition,  it  maintains a local prediction model $f_i$ for the user-defined pattern $\mathcal{P}$. The online predictions about the full match of  the pattern $\mathcal{P}$ in $s_i$ is provided for each new arriving event tuple, based on the current received event $ \ e_t \in s_i \ $ and the observed previous events sequence $\{e_j \in s_i \mid  j \text{ <} t\}$. In summary, we have multiple running instances of an online prediction algorithm on distributed nodes for multiple input event streams, each instance  provides online predications about a defined pattern of events. As an illustrative application domain, we consider massive event streams that describe trajectories of  moving objects, more specifically, event streams of moving vessels in the context of maritime surveillance.  As shown in Example \ref{example:maritime}.

\begin{example} %change it to example1 and sentances order%
	Let us consider a set of possible event types
	$$\Sigma=\{changeInSpeed,stopMoving,changeInTurn\}$$
And an example of event tuple structure that describes trajectory of a moving vessel
$$e_i=(vesselId,type,timestamp,longitude,latitude,speed)$$ such that $type \in \Sigma$
. Hence, we can define a pattern $\mathcal{P_j}$ that represents speed change followed by change in turn:  $$P_j=changeInSpeed.changeInTurn$$
\label{example:maritime}
\end{example}
The defined pattern $\mathcal{P_j}$ is monitored over each event stream $s_i$  by a  predictor nodes  $n_i$  that maintains a local prediction model $f_i$, where there is one node for each vessel's event stream.  The prediction model $f_i$ gives the ability to provide an online predictions about when the pattern will be completed in the form of an expected number of future events before a full match does occur.

 \subsection{The Proposed Approach}
 \par We aim to design and develop a scalable and distributed patterns prediction system over massive input event streams (e.g., event streams of moving objects). We  exploit the event forecasting with Pattern Markov Chains \cite{alevizos2017event} as the base prediction model (i.e., $f_i$). We propose to enable the dynamic merge of the prediction models of the input event streams, by adapting the distributed online predication protocol \cite{kamp2014communication} to synchronize the distributed  models, i.e., Markov transitions probabilities of the Pattern Markov Chain (PMC) predictors.

 \par We propose a $synchronization operation$  for the distributed Pattern Markov Chain (PMC) models based on the maximum-likelihood estimation \citep{anderson1957statistical} for the transition probabilities matrix of the underlaying Markov Chain described by
 \begin{equation}
 \label{eq:pi_estim}
 \hat{p}_{i,j}=\frac{\sum_{k \in K} n_{k,i,j}}{\sum_{k \in K} \sum_{l \in L} n_{k,i,l}}
 \end{equation}

 \par Our approach relies on enabling the collaborative learning between the prediction models of  the input event streams. By doing so, we assume that the underlying event streams belong to the same  distribution and share the same behavior (e.g., mobility patterns). We claim that assumption is reasonable in many application domains, for instance, in the context of maritime surveillance, vessels travel through defined routes by International Maritime Organization (IMO). Additionally, vessels have similar mobility patterns in specific areas such as moving with low speed and multiple turns near the ports \cite{pallotta2013vessel,liu2014knowledge}. That allows our system to dynamically construct a coherent global prediction model for all input event streams based on merging its local models. %We will empirically investigate the effect of enabling the distributed online learning over %

  \par Our proposed approach is expected to impose a speed up in the learning of the prediction models with less training data, in addition, we expect to gain an improvement of the predictive performance compared to the no-distributed  version of event forecasting with Pattern Markov Chains system.
  %Also it is adaptive to the non-stationary data streams that shows a concept drift by the continuously adjusting the predictions models based on the change of input event stream characteristics (i.e., by the continuous clustering integration with distribute online learning).%

 %An outline of our approach is given in $Algorithm$ ~\ref{alg:our_approach}.

%\begin{algorithm}[h!]

%	\caption{Our Approach}
%	check figure 4 in \cite{lee2007trajectory}
%	\label{alg:our_approach}
%\end{algorithm}
% add algorthim table describes the whole approach.

% In thesis, we will also consider another research direction concerning the extension of forecasting Markov chain to  higher order by including additional contextual features of the event such as  weather conditions of moving entities. We will empirically evaluate the effect of this extension over the prediction quality.
%

% pattern defination as sequence or regex of the events types of the input stream
% group of moving objects
% adding illistruating figure


\chapter{An Example \simplesine Simulation}
\label{sec:simplesine-sim}

In the following chapters,
we use the \simplesine model extensively as part of simulations
to illustrate \TrickHLA\ in action.
In this chapter, we introduce a non-HLA \simplesine simulation
as a way to explain the basics of how the model may be used with Trick,
and we do so without any \TrickHLA\ distractions.

% ----------
\section{\tt SIM\_simplesine\_pubsub}

In this simulation, there are two {\tt sim\_object}s:
a {\em publisher} and a {\em subscriber}.\footnote{
This publisher/subscriber terminology here is only suggestive.
There is no distributed computing going on.
Data only moves from one {\tt sim\_object} to another within a single process.
Nevertheless, the simulation is a fair way to introduce how \simplesine
data structure and functions are used in Trick \sdefine and input files.
}
The publisher generates a sine wave using the analytic equations
and periodically copies the state to the subscriber.
The subscriber propagates the state approximately between updates from
the publisher.
Based on the analytic equations, the subscriber also calculates an error
in the approximate propagation.

The motivation for having the publisher and subscriber propagate the state
differently is to illustrate a technique that is useful for HLA simulations.
The owner of some data might simulate it at a very high rate but
send updates at a lower frequency.
In between these updates, a subscriber may use an approximate method to
extrapolate the data until the next update arrives.\footnote{
  Extrapolation alternatives include doing nothing, in which case the
  data increments in discontinuous steps as the remote data arrive;
  dead reckoning, in which the data are extrapolated based on derivatives;
  or numerical integration of an approximate (lower fidelity) model, in
  which case the discontinuities on the subscriber side are hopefully
  reduced sufficiently to allow the subscriber's simulation to proceed.
}
% ----------
\section{\sdefine}
\label{sec:simplesine-pubsub-sdefine}

The {\tt SIM\_simplesine\_pubsub} \sdefine file is shown below. It consists of

\begin{itemize}
  \item{
    Some {\tt \#define} statements that set relevant frequencies for
    state propagation and data copying.
  }
  \item{
    The {\tt sim\_object}s -- the usual Trick {\tt sys} object and
    publisher and subscriber objects.
  }
  \item{
    An {\tt integrate} statement which enables Trick numerical integration
    for the subscriber.
  }
\end{itemize}

\begin{lstlisting}[caption={{\tt SIM\_simplesine\_pubsub} \sdefine file},label={list:SIM-pubsub-sdefine}]
#define PROPAGATE_TIMESTEP 0.25
#define COPY_TIMESTEP 5.0

sim_object
{
  sim_services/include: EXECUTIVE exec (sim_services/include/executive.d) ;

  (automatic) sim_services/input_processor:
    input_processor( INPUT_PROCESSOR* IP = &sys.exec.ip ) ;
} sys ;

sim_object
{
  simplesine: simplesine_T simplesine (simplesine/data/simplesine.d);

  (initialization) simplesine:
    simplesine_calc(
      simplesine_T* P = &publisher.simplesine,
      double t = sys.exec.out.time );

  // Propagate the state using the analytic equations.
  (PROPAGATE_TIMESTEP, scheduled) simplesine:
    simplesine_calc(
      simplesine_T* P = &publisher.simplesine,
      double t = sys.exec.out.time );

  // Copy the propagated state to the subscriber.
  (COPY_TIMESTEP, scheduled) simplesine:
    simplesine_copyState(
      simplesine_state_T* fromP = &publisher.simplesine.state,
      simplesine_state_T* toP = &subscriber.simplesine.state );
} publisher ;

sim_object
{
  sim_services/include: INTEGRATOR integ (simplesine/data/integ.d);
  simplesine: simplesine_T simplesine (simplesine/data/simplesine.d);
  simplesine: simplesine_T err (simplesine/data/simplesine.d);

  (initialization) simplesine:
    simplesine_calc(
      simplesine_T* P = &subscriber.simplesine,
      double t = sys.exec.out.time );

  // deriv/integ jobs to propagate the state differential equation
  (derivative) simplesine:
    simplesine_deriv( simplesine_T* p = &subscriber.simplesine );
  (integration) simplesine:
    simplesine_integ(
      INTEGRATOR* I = &subscriber.integ,
      simplesine_T* p = &subscriber.simplesine );

  // calculate the error between the integrated state and the true state
  (PROPAGATE_TIMESTEP, scheduled) simplesine:
    simplesine_calcError(
      double t = sys.exec.out.time,
      simplesine_T* s = &subscriber.simplesine,
      simplesine_state_T* err = &subscriber.err.state );
} subscriber ;

integrate (PROPAGATE_TIMESTEP) subscriber;
\end{lstlisting}
% ----------
\section{Input Files}

The input files for this simulation are located in the {\tt RUN\_1} directory
and are summarized below.

\begin{itemize}
\item{
  {\tt input\_noCopy\_noInteg}.
  In this input file,
  the publisher never sends data to the subscriber, and
  the subscriber does not propagate its local state.
  The motivation here is to illustrate that nothing really happens
  on the subscriber side until the publisher sends data.
}
\item{
  {\tt input\_noInteg}.
  This input file illustrates the arrival of data at the subscriber from
  the publisher.
  By not propagating the subscriber state, the discrete arrival of
  updates is readily evident.
  In some simulations in the subsequent chapter,
  we will use this technique to illustrate the arrival of HLA data.
}
\item{
  {\tt input}.
  This file illustrates the simulation running as it is intended:
  the publisher sends data periodically to the subscriber,
  and the subscriber integrates those data in between updates.
  In this case the harmonical oscillator is so simple that the numerical
  integration is a very good approximation to the true system.
}
\end{itemize}

The first two files illustrate how to disable specific Trick jobs from
the input file using the {\tt JOB} directive.
In {\tt input\_noCopy\_noInteg}, the publisher's
publisher-to-subscriber copy job is disabled
as well as the subscriber's numerical integration jobs.
In {\tt input\_noInteg}, the subscriber's numerical integration jobs are
disabled.
The input files are shown below.

\begin{lstlisting}[caption={{\tt SIM\_simplesine\_pubsub} input file, {\tt input\_noCopy\_noInteg}},label={list:SIM-pubsub-input-noCopy-noInteg}]
#include "S_default.dat"
#include "Log_data/states.d"
#include "Modified_data/realtime.d"
#include "Modified_data/publisher.d"
#include "Modified_data/subscriber.d"

JOB publisher.simplesine_copyState(&publisher.simplesine) = Off;

JOB subscriber.simplesine_deriv(&subscriber.simplesine) = Off;
JOB subscriber.simplesine_integ(&subscriber.integ) = Off;

stop = 32.5;
\end{lstlisting}

\begin{lstlisting}[caption={{\tt SIM\_simplesine\_pubsub} input file, {\tt input\_noInteg}},label={list:SIM-pubsub-input-noInteg}]
#include "S_default.dat"
#include "Log_data/states.d"
#include "Modified_data/realtime.d"
#include "Modified_data/publisher.d"
#include "Modified_data/subscriber.d"

JOB publisher.simplesine_copyState(&publisher.simplesine) = Off;

stop = 32.5;
\end{lstlisting}

\begin{lstlisting}[caption={{\tt SIM\_simplesine\_pubsub} input file, {\tt input}},label={list:SIM-pubsub-input}]
#include "S_default.dat"
#include "Log_data/states.d"
#include "Modified_data/realtime.d"
#include "Modified_data/publisher.d"
#include "Modified_data/subscriber.d"

stop = 32.5;
\end{lstlisting}

% ----------
\section{Output}

Output from the simulation with {\tt input\_noCopy\_noInteg}
is shown in Figure~\ref{fig:SIM-pubsub-input-noCopy-noInteg}.
The plot shows the evolution of the sine wave for approximately
ten cycles.
The publisher state ($x(t)$ and $\dot{x}(t)$) evolve as expected.
The subscriber state is flatlined at its initial conditions,
since data never arrive from the publisher and the subscriber's
numerical propagation is disabled.

\begin{figure}[b]
  \begin{center}
    \includegraphics[width=4.5in]{TrickHLAUser-prelim-SIM-pubsub-input-noCopy-noInteg.png}
  \end{center}
\caption{Output from {\tt SIM\_simplesine\_pubsub} using input file {\tt input\_noCopy\_noInteg}}
\label{fig:SIM-pubsub-input-noCopy-noInteg}
\end{figure}

Output from the simulation with {\tt input\_noInteg}
is shown in Figure~\ref{fig:SIM-pubsub-input-noInteg}.
It clearly shows the discrete transfer of data from the publisher to the
subscriber.
Between the data updates, the subscriber state remains constant,
since there is still no numerical intregration on the subscriber side.
This manifests itself in errors which grow significantly until the next
update arrives, at which point the errors reset to zero.

\begin{figure}[b]
  \begin{center}
    \includegraphics[width=4.5in]{TrickHLAUser-prelim-SIM-pubsub-input-noInteg.png}
  \end{center}
\caption{Output from {\tt SIM\_simplesine\_pubsub} using input file {\tt input\_noInteg}}
\label{fig:SIM-pubsub-input-noInteg}
\end{figure}

Output from the simulation with {\tt input}
is shown in Figure~\ref{fig:SIM-pubsub-input}.
In this case, the subscriber state is ``smoothed'' in between data updates,
since the subscriber numerical integration has been enabled.
Note that there are still errors which grow between updates;
however, in this case the magnitude of those error has diminished by several
orders of magnitude.

\begin{figure}[b]
  \begin{center}
    \includegraphics[width=4.5in]{TrickHLAUser-prelim-SIM-pubsub-input.png}
  \end{center}
\caption{Output from {\tt SIM\_simplesine\_pubsub} using input file {\tt input}}
\label{fig:SIM-pubsub-input}
\end{figure}

%
% print the figures before moving to the next chapter
%
\clearpage


\newpage\section{Data | Empirical results}\label{sec:results}

\subsection{Subsection}

Some citation: \citet{Bowman:1997}.

A table:
\begin{table}[H]
	\begin{center}
		\begin{tabular}{l|rrrr||rr}\hline\hline
			&\multicolumn{4}{c}{L\'evy}&\multicolumn{2}{c}{Gaussian} \\
			\hline
			& $b_0$ & $b_1$ & $a_1$ & $a_2$ & $a_1$ & $a_2$\\
			\hline
			Estimate & 1.000 & 74.268 & $-0.192$ &  0.638& $0.686$ &  $-0.154$\\
			Std. error & 10.158 & 0.288 & 0.204 & 0.604 & 0.021 &  0.025\\
			\hline\hline
		\end{tabular}
		\caption{CARMA(2,1) Coefficient estimates of the CARMA-L\'{e}vy process), CARMA(2,0) of the Gaussian process} %\label{tab:CARMAcoef}
	\end{center}
\end{table}

\subsection{More subsections}
Link/refer to figures: Figure \ref{fig:DRP}.

More citation: \cite{Weron:2008}


\documentclass[epsfig,10pt,fullpage]{article}

\newcommand{\LabNum}{9}
\newcommand{\CommonDocsPath}{../../../common/docs}
\input{\CommonDocsPath/preamble.tex}

\begin{document}

\centerline{\huge Digital Logic}
~\\
\centerline{\huge Laboratory Exercise \LabNum}
~\\
\centerline{\large A Simple Processor}
~\\

Figure~\ref{fig:fig1} shows a digital system that contains a number of 16-bit registers,
a multiplexer, an adder/subtracter, and a control unit (finite state machine).  Information
is input to this system via the 16-bit {\it DIN} input, which is loaded into the {\it IR}
register. Data can be transferred through the 16-bit wide multiplexer from one register
in the system to another, such as from register {\it IR} into one of the {\it general
purpose} registers $r0, \ldots, r7$.  The multiplexer's output is called {\it Buswires}
in the figure because the term {\it bus} is often used for wiring that allows data to be
transferred from one location in a system to another. The FSM controls the {\it Select}
lines of the multiplexer, which allows any of its inputs to be transferred to any register
that is connected to the bus wires.

~\\
The system can perform different operations in each clock cycle, as governed by the FSM.
It determines when particular data is placed onto the bus wires and controls which of the
registers is to be loaded with this data. For example, if the FSM selects $r0$ as the output of the
bus multiplexer and also asserts $A_{in}$, then the contents of register $r0$ will be loaded on the
next active clock edge into register {\it A}.

~\\
Addition or subtraction of signed numbers is performed by using the multiplexer to first
place one 16-bit number onto the bus wires, and then loading this number into register {\it A}.
Once this is done, a second 16-bit number is placed onto the bus, the adder/subtracter
performs the required operation, and the result is loaded into register {\it G}. The
data in {\it G} can then be transferred via the multiplexer to one of the other registers,
as required.

\begin{figure}[H]
	\begin{center}
		\includegraphics[scale = 0.8]{figures/figure1.pdf}
	\end{center}
	\caption{A digital system.}
	\label{fig:fig1}
\end{figure}

\newpage
\noindent
A system like the one in Figure~\ref{fig:fig1} is often called a {\it processor}. It
executes operations specified in the
form of {\it instructions}. Table~\ref{tab:instructions} lists the instructions that this
processor supports. The left column shows the name of an instruction and its operands.
The meaning of the syntax {\it rX} $\leftarrow$ {\it Op2} is that the second operand,
{\it Op2}, is loaded into register {\it rX}. The operand {\it Op2} can be either a
register, {\it rY}, or {\it immediate data}, \#{\it D}.

\begin{table}[H]
\begin{center}
\begin{tabular}{rl|c}
   \multicolumn{2}{c|}{Instruction} & Function performed \\ \hline
   \rule[0.01in]{0in}{0.15in}{\it mv} & {\it rX}, $Op2$ & {\it rX} $\leftarrow Op2$ \\
		  \rule[-0.075in]{0in}{0.2in}{\it mvt} & {\it rX,} \#{\it D} & {\it rX$_{15-8}$} $\leftarrow$ {\it D$_{15-8}$}\\
   \rule[-0.075in]{0in}{0.2in}{\it add} & {\it rX}, $Op2$ & {\it rX} $\leftarrow$ {\it rX} + $Op2$ \\
   \rule[-0.075in]{0in}{0.2in}{\it sub} & {\it rX}, $Op2$ & {\it rX} $\leftarrow$ {\it rX} $-$ $Op2$ \\
\end{tabular}
\caption{Instructions performed in the processor.}
\label{tab:instructions}
\end{center}
\end{table}

\noindent
Instructions are loaded from the external input {\it DIN}, and stored into the {\it IR} register,
using the connection indicated in Figure~\ref{fig:fig1}. Each instruction is {\it encoded} using
a 16-bit format. If $Op2$ specifies a register, then the instruction encoding is
\texttt{III0XXX000000YYY}, where \texttt{III} specifies the instruction, \texttt{XXX} gives
the {\it rX} register, and \texttt{YYY} gives the {\it rY} register. If $Op2$ specifies
immediate data \#{\it D}, then the encoding is
\texttt{III1XXXDDDDDDDDD}, where the 9-bit field \texttt{DDDDDDDDD} represents the constant data.
Although only two bits are needed to encode our four instructions, we are using three bits because
other instructions will be added to the processor later. Assume that \texttt{III} $= 000$ for
the {\it mv} instruction, $001$ for {\it mvt}, $010$ for {\it add}, and $011$ for {\it sub}.

~\\
The {\it mv} instruction ({\it move}) copies the contents of one register into
another, using the syntax \texttt{mv} \texttt{rX,rY}. It can also be used to initialize a
register with immediate data, as in \texttt{mv} \texttt{rX,\#D}.  Since the data {\it D}
is represented inside the encoded instruction using only nine bits, the processor has to
{\it zero-extend} the data, as in \texttt{0000000D$_{8-0}$}, before loading it into
register~{\it rX}.  The {\it mvt} instruction ({\it move top}) is used to initialize the
most-significant byte of a register.  For {\it mvt}, only eight bits of the {\it D} field in
the instruction are used, so that \texttt{mvt} \texttt{rX,\#D} loads the value
\texttt{D$_{15-8}$00000000} into {\it rX}. As an example, to load register $r0$ with the
value \texttt{0xFF00}, you would use the instruction \texttt{mvt r0,\#0xFF00}.  The instruction
\texttt{add} \texttt{rX,rY} produces the sum {\it rX} $+$ {\it rY} and loads the result
into {\it rX}. The instruction \texttt{add} \texttt{rX,\#D} produces the
sum {\it rX} $+$ {\it D}, where {\it D} is zero-extended to 16 bits, and saves the result
in {\it rX}. Similarly, the {\it sub} instruction generates
either {\it rX} $-$ {\it rY}, or {\it rX} $-$ \#{\it D} and loads the result into {\it rX}.

~\\
Some instructions, such as an {\it add} or {\it sub}, take a few clock cycles to complete,
because multiple transfers have to be performed across the bus. The finite state machine in the
processor ``steps through'' such instructions, asserting the control signals needed in
successive clock cycles until the instruction has completed.  The processor starts executing
the instruction on the {\it DIN} input when the {\it Run} signal is asserted and the processor
asserts the {\it Done} output when the instruction is finished.  Table~\ref{tab:control_signals}
indicates the control signals from Figure~\ref{fig:fig1} that have to be
asserted in each time step to implement the instructions in Table~\ref{tab:instructions}.  The
only control signal asserted in time step $T_0$, for all instructions, is {\it IR}$_{in}$.
The meaning of {\it Select = rY} or {\it IR} in the table is that the multiplexer selects
either register {\it rY} or the immediate data in {\it IR}, depending on the value of $Op2$.
For the {\it mv} instruction, when {\it IR} is selected the multiplexer outputs
\texttt{0000000DDDDDDDDD}, and for {\it mvt} the multiplexer outputs \texttt{DDDDDDDD00000000}.
Only signals from Figure~\ref{fig:fig1} that have to be asserted in each time
step are listed in Table~\ref{tab:instructions}; all other signals are not asserted. The
meaning of {\it AddSub} in step $T_2$ of the {\it sub} instruction is that this signal is set
to 1, and this setting causes the adder/subtracter unit to perform subtraction using
2's-complement arithmetic.

~\\
The processor in Figure~\ref{fig:fig1} can perform various tasks by using a sequence of
instructions. For example, the sequence below loads the number 28 into register $r0$ and then
calculates, in register $r1$, the 2's complement value $-28$.

\begin{minipage}[t]{15 cm}
\begin{lstlisting}
       mv    r0, #28        // original number = 28
       mvt   r1, #0xFF00
       add   r1, #0x00FF    // r1 = 0xFFFF
       sub   r1, r0         // r1 = 1's-complement of r0
       add   r1, #1         // r1 = 2's-complement of r0 = -28
\end{lstlisting}
\end{minipage}

\begin{table}[H]
\begin{center}
\begin{tabular}{r|c|c|c|c|}
\multicolumn{1}{c}{~} & \multicolumn{1}{c}{$T_0$} & \multicolumn{1}{c}{$T_1$} & \multicolumn{1}{c}{$T_2$} & \multicolumn{1}{c}{$T_3$} \rule[-0.075in]{0in}{0.25in}\\ \cline{2-5}
{\it mv~} & {\it IR}$_{in}$ & \rule[-0.075in]{0in}{0.25in}{\it Select} = {\it rY} or {\it IR}, &  &  \\
~ & ~ & {\it rX$_{in}$}, {\it Done} &  &  \\ \cline{2-5}
{\it mvt~} & {\it IR}$_{in}$ & \rule[-0.075in]{0in}{0.25in}{\it Select} = {\it IR}, &  &  \\
~ & ~ & {\it rX$_{in}$}, {\it Done} &  &  \\ \cline{2-5}
\rule[-0.075in]{0in}{0.25in}{\it add~} & {\it IR}$_{in}$ & {\it Select} = {\it rX}, & {\it Select} = {\it rY} or {\it IR}, & {\it Select = G}, {\it rX$_{in}$}, \\
~ & ~ & {\it A$_{in}$} &  {\it G$_{in}$} & {\it Done} \\
\cline{2-5}
\rule[-0.075in]{0in}{0.25in}{\it sub~} & {\it IR}$_{in}$ & {\it Select} = {\it rX}, & {\it Select} = {\it rY} or {\it IR}, & {\it Select = G}, {\it rX$_{in}$}, \\
~ & ~ & {\it A$_{in}$} &  {\it AddSub}, {\it G$_{in}$} & {\it Done} \\
\cline{2-5}
\end{tabular}
\caption{Control signals asserted in each instruction/time step.}
\label{tab:control_signals}
\end{center}
\end{table}

\section*{Part I}
\addcontentsline{toc}{1}{Part I}
Implement the processor shown in Figure~\ref{fig:fig1} using VHDL code, as follows:
\begin{enumerate}
\item Make a new folder for this part of the exercise.
Part of the VHDL code for the processor is shown in parts $a$ to $c$ of
Figure~\ref{fig:fig2}, and a more complete version of the code is provided with this exercise,
in a file named {\it proc.vhd}. You can modify this code to suit your own coding style
if desired---the provided code is just a suggested solution. Fill in the missing parts of
the VHDL code to complete the design of the processor.

\lstset{language=VHDL,numbers=none,escapechar=|}
\begin{figure}[h]
\begin{center}
\begin{minipage}[t]{15 cm}
\begin{lstlisting}[name=proc]
ENTITY proc IS
    PORT ( DIN                 : IN  STD_LOGIC_VECTOR(15 DOWNTO 0);
           Resetn, Clock, Run  : IN  STD_LOGIC;
           Done                : BUFFER  STD_LOGIC);
END proc;

ARCHITECTURE Behavior OF proc IS
    |$\ldots$| declare components

    TYPE State_type IS (T0, T1, T2, T3);
    SIGNAL Tstep_Q, Tstep_D: State_type;
    |$\ldots$|
    CONSTANT mv : STD_LOGIC_VECTOR(2 DOWNTO 0) := "000";
    CONSTANT mvt : STD_LOGIC_VECTOR(2 DOWNTO 0) := "001";
    CONSTANT add : STD_LOGIC_VECTOR(2 DOWNTO 0) := "010";
    CONSTANT sub : STD_LOGIC_VECTOR(2 DOWNTO 0) := "011";
    CONSTANT Sel_R0 : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0000";
    |$\ldots$|
    CONSTANT Sel_R7 : STD_LOGIC_VECTOR(3 DOWNTO 0) := "0111";
    CONSTANT Sel_G : STD_LOGIC_VECTOR(3 DOWNTO 0) := "1000";
    CONSTANT Sel_D : STD_LOGIC_VECTOR(3 DOWNTO 0) := "1001";
    CONSTANT Sel_D8 : STD_LOGIC_VECTOR(3 DOWNTO 0) := "1010" ;
             -- Sel_D is immediate data, Sel_D8 is immediate data << 8
BEGIN
\end{lstlisting}
\end{minipage}
\caption{Skeleton VHDL code for the processor. (Part $a$)}
\label{fig:fig2}
\end{center}
\end{figure}

\begin{center}
\begin{minipage}[t]{15 cm}
\begin{lstlisting}[name=proc]
    III <= IR(15 DOWNTO 13);
    IMM <= IR(12);
    rX <= IR(11 DOWNTO 9);
    rY <= IR(2 DOWNTO 0);
    decX: dec3to8 PORT MAP (rX, Xreg);

    statetable: PROCESS(Tstep_Q, Run, Done)
    BEGIN
        CASE Tstep_Q IS
            WHEN T0 =>    -- data is loaded into IR in this time step
                IF Run = '0' THEN Tstep_D <= T0;
                ELSE Tstep_D <= T1; END IF;
            WHEN T1 =>
            |$\ldots$|
        END CASE;
    END PROCESS;

    controlsignals: PROCESS (Tstep_Q, III, IMM, Xreg, rX, rY)
    BEGIN
        Done <= '0'; Ain <= '0'; |$\ldots$| default values for signals
        CASE Tstep_Q IS
            WHEN T0 => -- store DIN in IR as long as Tstep_Q = 0
                IRin <= '1';
            WHEN T1 => -- define signals in time step T1
                CASE III IS
                    WHEN mv =>
                        IF IMM = '0' THEN Sel <= '0' & rY;
                        ELSE Sel <= Sel_D; END IF;
                        Rin <= Xreg;
                        Done <= '1';
                    WHEN mvt =>
                    |$\ldots$|
                END CASE;
            WHEN T2 => -- define signals in time step T2
                CASE III IS
                    |$\ldots$|
                END CASE;
            WHEN T3 => -- define signals in time step T3
                |$\ldots$|
        END CASE;
    END PROCESS;

    fsmflipflops: PROCESS (Clock, Resetn, Tstep_D)
    BEGIN
        IF (Resetn = '0') THEN
            |$\ldots$|
    reg_0:  regn PORT MAP (BusWires, Rin(0), Clock, R0);
    reg_1:  regn PORT MAP (BusWires, Rin(1), Clock, R1);
    |$\ldots$|
    reg_7:  regn PORT MAP (BusWires, Rin(7), Clock, R7);
    |$\ldots$| instantiate other registers |and| the adder/subtracter unit
\end{lstlisting}
\end{minipage}
\end{center}

\begin{center}
Figure 2: Skeleton VHDL code for the processor. (Part $b$)
\end{center}

\begin{center}
\begin{minipage}[t]{15 cm}
\begin{lstlisting}[name=proc]
    -- define the internal bus
    busmux: PROCESS (Sel, R0, R1, R2, R3, R4, R5, R6, R7, G, IR)
    BEGIN
        CASE Sel IS
            WHEN Sel_R0 => BusWires <= R0;
            WHEN Sel_R1 => BusWires <= R1;
            |$\ldots$|
            WHEN Sel_R7 => BusWires <= R7;
            WHEN Sel_G => BusWires <= G;
            WHEN Sel_D => BusWires <= "0000000" & IR(8 DOWNTO 0);
            WHEN Sel_D8 => BusWires <= IR(7 DOWNTO 0) & "00000000";
            WHEN OTHERS => BusWires <= (OTHERS => '-');
        END CASE;
    END PROCESS;
END Behavior;

LIBRARY ieee;
USE ieee.std_logic_1164.all;

ENTITY dec3to8 IS
    PORT ( W   : IN   STD_LOGIC_VECTOR(2 DOWNTO 0);
           Y   : OUT  STD_LOGIC_VECTOR(0 TO 7));
END dec3to8;

ARCHITECTURE Behavior OF dec3to8 IS
BEGIN
    PROCESS (W)
    BEGIN
        CASE W IS
            WHEN "000" => Y <= "10000000";
            WHEN "001" => Y <= "01000000";
            WHEN "010" => Y <= "00100000";
            |$\ldots$|
            WHEN "110" => Y <= "00000010";
            WHEN "111" => Y <= "00000001";
            WHEN OTHERS => Y <= "00000000";
        END CASE;
    END PROCESS;
END Behavior;
\end{lstlisting}
\end{minipage}
\end{center}

\begin{center}
Figure 2: Skeleton VHDL code for the processor. (Part $c$)
\end{center}

~\\
\item Set up the required subfolder and files so that your VHDL code can be compiled and
simulated using the ModelSim Simulator to verify that your processor works properly.
An example result produced by using {\it ModelSim} for a correctly-designed circuit
is given in Figure~\ref{fig:fig3}.  It shows the value \texttt{0x101C} being loaded into {\it IR}
from {\it DIN} at time 30 ns. This pattern represents the instruction \texttt{mv r0,\#28},
where the immediate value $D = 28$ (\texttt{0x1C}) is loaded into $r0$ on the clock edge at 50 ns.
The simulation results then show the instruction \texttt{mvt~r1,\#0xFF00} at 70 ns,
\texttt{add r0,\#0xFF} at 110 ns, and \texttt{sub r1,r0} at 190 ns.

You should perform a thorough simulation of your processor with the ModelSim simulator. A
sample VHDL testbench file, {\it testbench.vht}, execution script, {\it testbench.tcl},
and waveform file, {\it wave.do} are provided along with this exercise.
\end{enumerate}
\begin{figure}[H]
	\begin{center}
		\includegraphics[scale=.95]{figures/figure3.png}
	\end{center}
	\caption{Simulation results for the processor.}
	\label{fig:fig3}
\end{figure}
\section*{Part II}
\addcontentsline{toc}{2}{Part II}
In this part we will implement the circuit depicted in Figure~\ref{fig:fig4}, in which a
memory unit and counter are connected to the processor. The
counter is used to read the contents of successive locations in the memory, and
this data is provided to the processor as a stream of instructions. To simplify the
design and testing of this circuit we have used separate clock signals, {\it PClock}
and {\it MClock}, for the processor and memory. Do the following:

\begin{enumerate}
\item A Quartus project file is provided along with this part of the exercise.  Use the
Quartus software to open this project, which is called {\it part2.qpf}.
\item A sample top-level VHDL file that instantiates the processor, memory unit, and
counter is shown in Figure~\ref{fig:procmem}. This code is provided in a file named
{\it part2.vhd}; it is the top-level file for the Quartus project {\it part2.qpf}. The
code instantiates a memory unit called {\it inst\_mem}. You have to create a VHDL file
that represents this memory unit by using the Quartus software, as described below.

~\\
\begin{figure}[H]
	\begin{center}
		\includegraphics[]{figures/figure4.pdf}
	\end{center}
	\caption{Connecting the processor to a memory unit and counter.}
	\label{fig:fig4}
\end{figure}
\newpage
\lstset{language=VHDL,numbers=none,escapechar=|}
\begin{figure}[h]
\begin{center}
\begin{minipage}[t]{15 cm}
\begin{lstlisting}[name=proc]
ENTITY part2 IS
PORT ( KEY   : IN   STD_LOGIC_VECTOR(1 DOWNTO 0);
       SW    : IN   STD_LOGIC_VECTOR(9 DOWNTO 0);
       LEDR  : OUT  STD_LOGIC_VECTOR(9 DOWNTO 0));
END part2;

ARCHITECTURE Behavior OF part2 IS
   |$\ldots$| declare components and signals
BEGIN
   Resetn <= SW(0);
   MClock <= KEY(0);
   PClock <= KEY(1);
   Run <= SW(9);
   U1: proc PORT MAP (DIN, Resetn, PClock, Run, Done);
   LEDR(0) <= Done;
   LEDR(9) <= Run;

   U2: inst_mem PORT MAP (pc, MClock, DIN);
   U3: count5 PORT MAP (Resetn, MClock, pc);
END Behavior;
|$\ldots$|
ENTITY count5 IS
PORT ( Resetn, Clock   : IN   STD_LOGIC;
       Q               : OUT  STD_LOGIC_VECTOR(4 DOWNTO 0));
END count5;

ARCHITECTURE Behavior OF count5 IS
   SIGNAL Count : STD_LOGIC_VECTOR(4 DOWNTO 0);
BEGIN
   PROCESS (Clock, Resetn)
   BEGIN
         IF (Resetn = '0') THEN
            Count <= "00000";
         ELSIF (rising_edge(Clock)) THEN
            Count <= Count + '1';
         END IF;
   END PROCESS;
   Q <= Count;
END Behavior;
\end{lstlisting}
\end{minipage}
\caption{VHDL code for the top-level entity.}
\label{fig:procmem}
\end{center}
\end{figure}

\item
A diagram of the memory unit that you need to create is depicted in Figure~\ref{fig:fig_ROM}.
Since this memory unit has only a read port, and no write port, it is called a {\it synchronous
read-only memory (synchronous ROM)}. Note that the memory unit includes a register for
synchronously loading addresses. This register is required due to the design of the memory
resources in the Intel FPGA chip.

Use the Quartus IP Catalog tool to create the memory unit, by clicking on
{\sf Tools} $>$ {\sf IP Catalog} in the Quartus software. In the IP Catalog window
choose the {\it ROM:~1-PORT} unit,
which is found under the {\sf Basic Functions $>$  On Chip Memory} category.
Select {\sf VHDL} as the type of output file to create, and give the file the name
{\it inst\_mem.vhd}.
Follow through the provided dialogue to create a memory that has one 16-bit
wide read data port and is 32 words deep. Figures~\ref{fig:fig5} and ~\ref{fig:fig6} show the
relevant pages and how to properly configure the memory.

\begin{figure}[t]
	\begin{center}
		\includegraphics[]{figures/figure_ROM.pdf}
	\end{center}
	\caption{The 32 {\sf x} 16 ROM with address register.}
	\label{fig:fig_ROM}
\end{figure}

\begin{figure}[H]
	\begin{center}
		\includegraphics[scale=1.0]{figures/figure5.png}
	\end{center}
	\caption{{Specifying memory size.}}
	\label{fig:fig5}
\end{figure}

To place processor instructions into the memory, you need to specify {\it initial values}
that should be stored in the memory when your circuit is programmed into the FPGA chip.
This can be done by initializing the memory using the contents of a {\it memory initialization
file (MIF)}. The appropriate screen is illustrated in Figure~\ref{fig:fig7}. We have specified
a file named {\it inst\_mem.mif}, which then has to be created in the folder that
contains the Quartus project. Clicking \texttt{Next} two more times will advance to the
\texttt{Summary} screen, which lists the names of files that will be created for the memory IP.
You should select {\it only} the VHDL file {\it inst\_mem.vhd}. Make sure that none of the
other types of files are selected, and then click \texttt{Finish}.

An example of a memory initialization file is given in
Figure~\ref{fig:fig_MIF}. Note that comments (\% $\ldots$ \%) are included in this file as a way of
documenting the meaning of the provided instructions.  Set the contents of
your {\it MIF} file such that it provides enough processor instructions to test your circuit.

\item The code in Figure~\ref{fig:procmem}, and the Quartus project, includes the necessary
port names and pin location assignments to implement the circuit on a DE-series board.
The switch {\it SW}$_{9}$ drives the processor's {\it Run} input, {\it SW}$_0$ is
connected to {\it Resetn}, {\it KEY}$_0$ to {\it MClock}, and {\it KEY}$_1$ to {\it PClock}.
The Run signal is displayed on {\it LEDR}$_{0}$ and {\it Done} is connected to {\it LEDR}$_{9}$.
\begin{figure}[H]
	\begin{center}
		\includegraphics[scale=1.0]{figures/figure6.png}
	\end{center}
	\caption{Specifying which memory ports are registered.}
	\label{fig:fig6}
\end{figure}

\begin{figure}[H]
	\begin{center}
		\includegraphics[scale=1.0]{figures/figure7.png}
	\end{center}
	\caption{Specifying a memory initialization file (MIF).}
	\label{fig:fig7}
\end{figure}

\item Use the ModelSim Simulator to test your VHDL code. Ensure
that instructions are read properly out of the ROM and executed by the processor. An example
of simulation results produced using ModelSim with the MIF file from
Figure~\ref{fig:fig_MIF} is shown in Figure~\ref{fig:fig_sim2}. The corresponding ModelSim
setup files are provided along with this exercise.
\item Once your simulations show a properly-working circuit, you may wish to download
it into a DE-series board. The functionality of the circuit on the board can be tested by
toggling the switches and observing the LEDs. Since the circuit's clock inputs are controlled
by pushbutton switches, it is possible to step through the execution of instructions and
observe the behavior of the circuit.
\end{enumerate}

\begin{figure}[H]
\begin{center}
\begin{minipage}[t]{12.5 cm}
\begin{tabbing}
{\bf DEPTH} = 32;\\
{\bf WIDTH} = 16;\\
{\bf ADDRESS\_RADIX} = HEX;\\
{\bf DATA\_RADIX} = BIN;\\
{\bf CONTENT}\\
{\bf BEGIN}\\
00	:	0001000000011100;~~~~~~\=\%~~mv  \=r0, \#0xFF00~~\=\% \kill
00	:	0001000000011100;	\>\% mv \>r0, \#28\>\%\\
01	:	0011001011111111; \>\% mvt \>r1, \#0xFF00\>\%\\
02	:	0101001011111111;	\>\% add  \>r1, \#0xFF\>\%\\
03	:	0110001000000000;	\>\% sub  \>r1, r0\>\%\\
04	:	0101001000000001;	\>\% add  \>r1, \#1\>\%\\
05	:	0000000000000000;\\
$\ldots$ (some lines not shown)\\
1F :	0000000000000000;\\
{\bf END};
\end{tabbing}
\end{minipage}
\end{center}
\caption{An example memory initialization file (MIF).}
\label{fig:fig_MIF}
\end{figure}

\begin{figure}[H]
	\begin{center}
		\includegraphics[scale=.95]{figures/figure8.png}
	\end{center}
	\caption{An example simulation output using the MIF in Figure~\ref{fig:fig_MIF}.}
	\label{fig:fig_sim2}
\end{figure}

\section*{Enhanced Processor}
\addcontentsline{toc}{3}{Enhanced Processor}
It is possible to enhance the capability of the processor so that the counter in
Figure~\ref{fig:fig4} is no longer needed, and so that the processor has the ability to
perform read and write operations using memory or other devices. These enhancements involve
adding new instructions to the processor, as well as other capabilities---they are
discussed in the next lab exercise.

\end{document}