%%This is a very basic article template.
%%There is just one section and two subsections.
\documentclass[a4paper,11pt]{article}
\usepackage[pdfborder= 0 0 0 1]{hyperref}
\usepackage{graphicx}

\begin{document}

\title{CONV-TTL-BLO HDL specifications}
\author{Carlos Gil Soriano\\BE-CO-HT\\
\href{mailto:carlos.gil.soriano@cern.ch}{\textbf{\textit{carlos.gil.soriano@cern.ch}}}}
\date{\today}
\maketitle

\begin{abstract}
This document tackles with:
\begin{itemize}
  \item HDL development priorities
  \item Memory mapping
\end{itemize}
\end{abstract}
\\
\tableofcontents

\pagebreak
\section{HDL schema}
The following schema is used as a reference for the HDL development:\\
\begin{figure}[htb]
    \begin{center}
      \includegraphics[scale=0.3, keepaspectratio]{Figures/HDLspecs.png}
            \caption{CONV-TTL-BLO HDL structure}
    \end{center}
\end{figure}

\subsection{Control}
It is the part that bridges the I2C frames to the correct wishbone module. The
tasks it is responsible of are: 
\begin{itemize}
  \item Correctly power-up the rest of the modules.
  \item Provide connectivity of all the wishbone registers via
  I2C. It manages control access to the registers.
\end{itemize}
\subsection{I2C slave}
An I2C slave is needed to receive the frames from the VME64x SERA and SERB pins
in P1 connector. This module will communicates with \textit{control hdl module}
in the following fashion:
\begin{itemize}
  \item It connects as a wishbone \textbf{slave} to control hdl core and
  provides interrupt lines for data reception and transmission.
\end{itemize}
The main reason of implementing a wishbone slave is that by dividing data
reception -\textit{i2c slave}- from control access -\textit{control}- the
development is more reliable and clear.\\ This module offers configuration
registers to ease the task of data assembly --for instance, the communication
schema in ELMA crate.
\subsection{Trigger}
The trigger manages the pulse repetition. The parameters handled that affect the
pulse repetition are:
\begin{itemize}
  \item \textbf{Debouncing} stages of the input pulse.
  \item \textbf{Pulse length} of the output pulse according to Standard
  Blocking definition.
  \item \textbf{Minimun spacing between pulses} to let the magnetizing current 
  of the transformer be drained off. It is also refered in other documents as
  \textit{Inactivity timeout upon output pulse is outputted}.
\end{itemize}
The pulses must be time-tagged. It can be achieved either by a
lossy time-tagging via i2c, or with a precise one via White Rabbit. Every
time-tag has appended event identifiers (metadata).
\subsubsection{Time-tagging Format}
The format of the time-tags should be defined. At this moment, an implementation
with 96 bits for timestamping with 32 bits of metadata is the default. A record
of the last 256 time-tags per channel is hold in the FPGA.
\subsection{Multiboot manager}
  The task of the \textit{Multiboot manager} is to manage a golden bitstream and
  another one to update the FPGA from. From within this module a FPGA
  reprogramming command is issued.
\subsection{EEPROM manager}
The module responsible to write into the EEPROM, read it back and reprogramming
the memory module. It should be targeted to interface directly with a MICRON
M25P32-VMF6P memory. It will be able to write the MAC address that will be used
by White Rabbit and block memory parts of the EEPROM.

\subsection{White Rabbit core}
Provides precise timestamping.
\pagebreak
\section{HDL development milestones}
The HDL development is scheduled to tackle with several milestones:
\begin{enumerate}
  \item \textit{i2c slave} module: verification
  \item \textit{Control} module: reset the rest of HDL cores. Bypassing
  i2c instrucctions to wishbone interface.
  \item \textit{Multiboot manager} module: multiboot between different
  precharged bitstreams.
  \item \textit{EEPROM manager} module: write a bitstream through the i2c interface.
  \item Integration of White Rabbit core: fine timestamping  
\end{enumerate}
\section{Wishbone memory map}
So as to access the devices thanks to \textit{CTDAH control} the
following memory map is proposed:
\begin{center}
\begin{tabular}{|c|c|c|c|}
\hline
&& \textbf{FIRST} & \textbf{LAST}\\
\textbf{NUMBER}&\textbf{DEVICE} & \textbf{WISHBONE} & \textbf{WISHBONE}\\  
&& \textbf{ADDRESS}  & \textbf{ADDRESS}\\
\hline
\hline
0 & Control & 0x0100 & 0x01FF \\
\hline
1 & I2C slave & 0x0200 &  0x02FF \\
\hline
2 & Trigger 1 & 0x0300 & 0x03FF \\
\hline
3 & Trigger 2 & 0x0400 & 0x04FF \\
\hline
4 & Trigger 3 & 0x0500 & 0x05FF \\
\hline
5 & Trigger 4 & 0x0600 & 0x06FF \\
\hline
6 & Trigger 5 & 0x0700 & 0x07FF \\
\hline
7 & Trigger 6 & 0x0800 & 0x08FF \\
\hline
8 & Multiboot manager & 0x0900 & 0x09FF \\
\hline
9 & EEPROM manager & 0x0A00 & 0x0AFF \\
\hline
10 & White Rabbit core & 0x0B00 & 0x0BFF \\
\hline
\hline
11 & EEPROM memory & 0x1000 &  0x1FFF \\
\hline
\end{tabular}
\end{center}
%\section{HDL modules}
%\subsection{i2c slave}
%w\subsection{trigger}

%$\section{Functional specifications}
%CTDAH board holds the logic that controls pulse conversion and forwarding.
%Three input and output signal levels can be handled: TTL, inverted-TTL and
%%Standard Blocking.
%The behaviour of the HDL is as follows:

%\begin{itemize}
%  \item Everytime an input pulse is detected, the pulse is converted to the
%  output level and time-tagged. Glitches are not forwarded.
%  \item The input events are detected and logged.
%  \item CTDAH communicates with a monitor board via I$^2$C through VME64x
%  connector. The monitor board can set CTDAH control parameters, receive
%  notifications from it, report problems affecting the backplane and reprogram
%  CTDAH FPGA.
%\end{itemize}
%
%A block diagram for the HDL core is shown below:\\
%
%\begin{figure}[htb]
%    \begin{center}
%      \includegraphics[scale=1, keepaspectratio]{BlockDiagram.png}
%            \caption{CTDAH HDL structure}
%    \end{center}
%\end{figure}
%
%
%
%\pagebreak
%\section{Technical specifications}
%
%
%
%\subsection{Memory mapping}
%
%
%\subsection{Time tagger register}
%Each time an input event is detected, it is time-tagged in the internal FPGA
%memory.\\
%A time-tag consist of six words. The first two words form the PULSE\_ID field
%and the later four ones, the UTC time-tag:
%
%\begin{center}
%\begin{tabular}{|c|c|}
%\hline
%0 & PULSE\_ID_U\\
%\hline
%1 & PULSE\_ID_L\\
%\hline
%2 & UTC_{UU}\\
%\hline
%3 & UTC_{UL}\\
%\hline
%4 & UTC_{LU}\\
%\hline
%5 & UTC_{LL}\\
%\hline
%\end{tabular}
%\end{center}
%\subsubsection{PULSE\_ID field}
%The PULSE\_ID$_L$ contains the length of the output pulse, in clock cycles. The
%PULSE\_ID$_U$ field is defined as follows:
%\begin{center}
%\begin{tabular}{|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|}
%\hline
%15 & 14 & 13 & 12 & 11 & 10 & 9 & 8 & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0\\
%\hline
%&  &  &  &  &  & \tiny{OM1} & \tiny{OM0} &  &  &  & \tiny{IOK} & \tiny{IFL} &
%\tiny{IFS} & \tiny{IM1} &\tiny{IM0}\\
%\hline 
%\end{tabular}
%\end{center}
%\\
%\subsubsection{UTC field}

\end{document}
