%==============================================================================
% Document header
%==============================================================================
\documentclass[a4paper,11pt]{article}

% Color package
\usepackage[usenames,dvipsnames,table]{xcolor}

% Hyperrefs
\usepackage[
  colorlinks = true,
  linkcolor  = black,
  citecolor  = black,
  urlcolor   = blue,
]{hyperref}

% Longtable
\usepackage{longtable}

% Graphics, multirow
\usepackage{graphicx}
\usepackage{multirow}

% Appendix package
\usepackage[toc,page]{appendix}

\usepackage{fancyhdr}
\setlength{\headheight}{15.2pt}
\pagestyle{fancy}
\fancyhead[L]{\nouppercase{\leftmark}}
\fancyhead[R]{}
\renewcommand{\footrulewidth}{0.4pt}

% Row number command
\newcounter{rownr}
\newcommand{\rownumber}{\stepcounter{rownr}\arabic{rownr}}

%==============================================================================
% Start of document
%==============================================================================
\begin{document}

%------------------------------------------------------------------------------
% Title
%------------------------------------------------------------------------------
\include{cern-title}

%------------------------------------------------------------------------------
% Revision history
%------------------------------------------------------------------------------
\pagebreak

\thispagestyle{empty}

\addcontentsline{toc}{section}{Licensing information}
\section*{Licensing information}

\noindent
This document is licensed under a Creative Commons Attribution-ShareAlike 4.0
International License. If you have not received a copy of the license along with this
work, see \\
\url{http://creativecommons.org/licenses/by-sa/4.0/}

\section*{Revision history}
\addcontentsline{toc}{section}{Revision history}


\centerline
{
  \rowcolors{2}{white}{gray!25}
  \begin{tabular}{l c p{.6\textwidth}}
  \hline
  \multicolumn{1}{c}{\textbf{Date}} & \multicolumn{1}{c}{\textbf{Version}} & \multicolumn{1}{c}{\textbf{Change}} \\
  \hline
  19-06-2013 & 1.00 & First version \\
  21-06-2013 & 1.01 & Added termination resistors to Fig.~\ref{fig:ttl-chan},~\ref{fig:invttl-chan} \\
  22-07-2013 & 1.02 & New title page and page layout \\
  26-07-2013 & 1.03 & Added additional documentation subsection \\
  05-08-2013 & 1.04 & Memory map is now appendix \\
  23-12-2013 & 1.05 & Added remote reprogramming support \\
  10-01-2014 & 1.06 & Added SNMP access sub-section \\
  06-03-2014 & 2.00 & Added support for diagnostics \\
  08-04-2014 & 2.10 & Changed max. pulse repetition frequency, replaced the timetag FIFO for a
                      ring buffer \\
  11-08-2014 & 2.20 & Various to make the document clearer. Made description in Table~\ref{tbl:syserr}
                      more concise; moved Figure~\ref{fig:sr-switches} from Section~\ref{sec:switches}
                      to Section~\ref{sec:diag-sw-rtmdet}; made slight modifications to Figure~\ref{fig:man-trig-fsm}
                      to make it fit on its page; added reference to schematics and OHWR project page
                      in Additional Documents section (under Section~\ref{sec:intro}) \\
  12-08-2014 & 2.21 & Small error corrections (\textit{writereg} instead of \textit{readreg} in Section~\ref{sec:diag-remote-reset},
                      and typo in Section~\ref{sec:reprog-bitstreams}), and addition of how to read gateware version in
                      Section~\ref{sec:reprog-bitstreams} \\
  26-09-2014 & 3.00 & Added latest per-channel timestamp readout and line status registers. \newline
                      \textbf{Note: this version changes the memory mapping of various modules} \\
  30-09-2014 & 3.01 & Added licensing information, made LSR.FRONTINV bits clearer (Appendix~\ref{app:conv-regs-lsr}),
                      added fallback to golden bitstream as system error (Section~\ref{sec:diag-syserr}) \\
  \hline
  \end{tabular}
}

%------------------------------------------------------------------------------
% List of figs, tables
%------------------------------------------------------------------------------
\pagebreak
\pdfbookmark[1]{\contentsname}{toc}
\tableofcontents
\listoffigures
\listoftables

%------------------------------------------------------------------------------
% List of abbreviations
%------------------------------------------------------------------------------
\pagebreak
\section*{List of Abbreviations}
\begin{tabular}{l l}
  FPGA   & Field-Programmable Gate Array \\
  I$^2$C & Inter-Integrated Circuit \\
  MIB    & Management Information Base \\
  OID    & Object identifier (in the sense of SNMP) \\
  PG     & Pulse Generator \\
  RTM    & Rear Transition Module \\
  SFP    & Small Form-factor Pluggable (connector) \\
  SNMP   & Simple Network Management Protocol \\
  TAI    & International Atomic Time (French abbreviation) \\
  VME    & VERSAmodule Eurocard \\
  WR     & White Rabbit \\
\end{tabular}
\addcontentsline{toc}{section}{List of abbreviations}

%======================================================================================
% SEC: Intro
%======================================================================================
\pagebreak
\section{Introduction}
\label{sec:intro}

CONV-TTL-BLO is an open hardware design \cite{ohwr} intended for replicating TTL and blocking
pulses (see Section~\ref{sec:pulse-def}). The main features of the board are:

\begin{itemize}
  \item VME64x form-factor
  \item Six independent pulse replication channels, each channel capable of replicating
  \begin{itemize}
    \item TTL to blocking
    \item TTL-BAR to blocking
    \item Blocking to TTL
    \item Blocking to TTL-BAR
    \item Blocking to blocking
    \item TTL to TTL
    \item TTL-BAR to TTL-BAR
  \end{itemize}
  \item Four general-purpose inverter channels
  \item Each channel has 50~$\Omega$ input termination
  \item Each channel capable of driving 50~$\Omega$ load
  \item SFP connector
  \item Diagnostics
  \begin{itemize}
    \item converter board ID
    \item gateware version
    \item unique board ID and temperature readout
    \item input line state readout
    \item state of on-board switches and RTM detection lines
    \item input pulse counters
    \item input pulse time-tagging
    \item manual pulse triggering
    \item remotely reset the FPGA logic
  \end{itemize}
  \item Remote reprogramming over I$^2$C lines on VME P1 connector
  \item Status LEDs
  \item Pulse LEDs for each replication channel
\end{itemize}

\begin{figure}[htbp]
  \centerline{\includegraphics[width=\textwidth, keepaspectratio]{fig/conv-sys-bd}}
  \caption{Simplified block diagram of the pulse conversion system} 
  \label{fig:conv-sys-bd}
\end{figure}

CONV-TTL-BLO is a VME64x front-module that can be used standalone as a TTL or
TTL-BAR pulse repeater using the six replication channels, or as a TTL to TTL-BAR
(and viceversa) converter using the four general-purpose inverter channels.

By combining the CONV-TTL-BLO with the CONV-TTL-RTM rear-transition module (RTM) in the rear
part of the VME crate, a flexible six-channel pulse conversion system can be obtained.
Such a system is shown in Figure~\ref{fig:conv-sys-bd}. TTL pulses arriving on an input
TTL channel are regenerated in the FPGA and sent on the channel's TTL output as well
as on the three blocking outputs on the RTM. Similarly, blocking pulses arriving on a
blocking input channel are regenerated in the FPGA and replicated on both the TTL
and blocking outputs of the channel.

CONV-TTL-BLO contains all active circuitry in a pulse conversion system. It handles
pulse generation and conversion from/to blocking, as well as galvanic isolation of
blocking outputs. CONV-TTL-RTM is a passive module used as an interface from the rear
part of the VME crate to the front module.

%------------------------------------------------------------------------------
% SUBSEC: Additional doc
%------------------------------------------------------------------------------
\subsection{Additional documentation}

\begin{itemize}
  \item CONV-TTL-BLO OHWR Project Page \cite{ctb-proj}
  \item CONV-TTL-BLO Schematics on CERN EDMS \cite{sch}
  \item CONV-TTL-BLO Hardware Guide \cite{ctb-hwguide}
  \item CONV-TTL-BLO HDL Guide \cite{ctb-hdlguide}
\end{itemize}

%======================================================================================
% SEC: Panels
%======================================================================================
\pagebreak
\section{Front and rear panels}
\label{sec:front-rear-panel}

Two panels exist in the context of the blocking pulse repeater boards. The first of these is the
\textit{front panel}, which corresponds to CONV-TTL-BLO boards contains various connectors
for TTL-level pulses and the SFP connector, as well as various status LEDs. The second is
the \textit{rear panel}, located on the other side of the VME backplane and corresponding
to CONV-TTL-RTM boards. The rear panel offers blocking pulse connectors and status
LEDs for pulse replication confirmation.

%--------------------------------------------------------------------------------------
% SUBSEC: Front panel
%--------------------------------------------------------------------------------------
\subsection{Front panel}

The front panel of CONV-TTL-BLO boards is shown in Figure~\ref{fig:fp}. It consists
of status LEDs and several ports; these are, from top to bottom:
\begin{itemize}
  \item System status LEDs
  \item Small form-factor pluggable (SFP) connector
  \item TTL (or TTL-BAR) pulse connectors and associated pulse LEDs
  \item General-purpose inverter channels
\end{itemize}

\begin{figure}[htbp]
    \centerline{\includegraphics[scale=.75, keepaspectratio]{fig/front-panel}}
    \caption{CONV-TTL-BLO panel (front panel)}
    \label{fig:fp}
\end{figure}

%--------------------------------------------------------------------------------------
\subsubsection{System status LEDs}
There are twelve bicolor status LEDs on the CONV-TTL-BLO front panel. The implemented
status LEDs are shown in Table \ref{tbl:status-leds}. Unimplemented system status
LEDs are \textit{off}.

\begin{table}[h]
\caption{System status LEDs on the CONV-TTL-BLO front panel}
\label{tbl:status-leds}
\centerline
{
  \rowcolors{2}{white}{gray!25}
  \begin{tabular}{l p{.75\textwidth}}
  \hline
  \multicolumn{1}{c}{\textbf{LED}} & \multicolumn{1}{c}{\textbf{Description}} \\
  \hline
  \textit{PW}  & Power LED \newline
                 -- \textbf{Green} when a valid CONV-TTL-BLO gateware is loaded
                 to the FPGA \\
  \textit{ERR} & Error LED \newline
                 -- \textbf{Red} when a system error occured (see Section~\ref{sec:diag-syserr}) \newline
                 -- \textbf{Off} otherwise \newline
                 In golden gateware v0.1 (see~\cite{ctb-gw-releases}), this LED lights \textit{red} when
                 no RTM is plugged in \\
  \textit{TTL} & TTL status LED \newline
                 -- \textbf{Green} when TTL logic is selected via the on-board selection switch \newline
                 -- \textbf{Off} when TTL-BAR logic is selected. \\
  \textit{I2C} & I$^2$C status LED \newline
                 -- \textbf{Flashes green} when an I$^2$C transfer takes places \newline
                 -- \textbf{Off} otherwise \\
  \hline
  \end{tabular}
}
\end{table}

%--------------------------------------------------------------------------------------
\subsubsection{SFP connector}
This connector is used to add White Rabbit (WR) support to the CONV-TTL-BLO boards.
If an optic fibre cable is connected to this socket, WR precise 
time-stamping can be added to CONV-TTL-BLO. Four status LEDs above the connector are provide
to show the status of the WR link.

WR is currently not supported by the FPGA gateware.

%--------------------------------------------------------------------------------------
\subsubsection{TTL inputs and outputs}
Six of the LEMO 00 connectors on the CONV-TTL-BLO board are TTL repeater
channels. Both front-panel inputs and outputs are TTL-level. The signal
type and the inputs and outputs can be either TTL or TTL-BAR, as selected by the
TTL switch (SW2.4, see Section~\ref{sec:pulse-ttl-vs-ttlbar}).

A simplified diagram of pulse repetition is shown in Figure~\ref{fig:ttl-chan},
more details can be found in Section~\ref{sec:pulse-rep}. If a TTL (TTL-BAR) pulse arrives
on a channel input, it is regenerated on the output of the same channel in TTL (TTL-BAR),
as well as the blocking outputs of the same channel on the rear panel, if a CONV-TTL-RTM
board with an attached CONV-TTL-RTM-BLO is present. Similarly, if a blocking pulse arrives
on the rear panel, it is replicated on the TTL output channel.

Each TTL replication channel has a pulse LED which flashes shortly whenever a pulse is replicated
on the channel. All TTL input channels are terminated with 50$\Omega$ resistors; TTL output channels are
not terminated.

\begin{figure}[h]
  \centerline{\includegraphics[scale=.75]{fig/ttl-chan}}
  \caption{Pulse repetition on front channel}
  \label{fig:ttl-chan}
\end{figure}

%--------------------------------------------------------------------------------------
\subsubsection{General-purpose inverters}
Four general-purpose TTL inverter channels can be found in the lower part of the front panel.
The output of a channel is always an inverted version of the channel input (Figure~\ref{fig:invttl-chan}).
No regeneration is performed on the input signal, nor is it in any way connected to the blocking outputs
on the RTM. The input signal is simply passed through an inverter and presented at the channel output.

\begin{figure}[h]
  \centerline{\includegraphics[scale=.85]{fig/invttl-chan}}
  \caption{TTL general-purpose inverter channel}
  \label{fig:invttl-chan}
\end{figure}

All general-purpose inputs are terminated with 50$\Omega$ resistors; the outputs are not
terminated.

%--------------------------------------------------------------------------------------
% SUBSEC: Rear panel
%--------------------------------------------------------------------------------------
\subsection{Rear panel}

The rear panel on CONV-TTL-BLO-RTM boards is shown in Figure~\ref{fig:rear-panel}. It contains the
input and output connectors, as well as pulse status LEDs for six blocking-level pulse channels. A blocking
pulse at the input connector of a channel is regenerated at the three outputs of the same channel in
blocking level and in TTL level at the output connector of the corresponding TTL channel on the front panel.

All blocking input channels have internal termination with 50~$\Omega$ resistors. Blocking outputs are
not terminated. Each output on a channel has a separate blocking driver capable of driving a 50~$\Omega$
load.

When a pulse is repeated on the output connector of a channel, the pulse status LED flashes briefly.

\begin{figure}[htbp]
  \centerline{\includegraphics[scale=.75]{fig/rear-panel}}
  \caption{CONV-TTL-BLO-RTM panel (rear panel)}
  \label{fig:rear-panel}
\end{figure}

%======================================================================================
% SEC: switches
%======================================================================================
\pagebreak
\section{On-board switches}
\label{sec:switches}

There are eight switches provided on-board the CONV-TTL-BLO, only two of which are
used. Figure~\ref{fig:switches} shows the switches and highlights the used ones, which
are also listed in Table~\ref{tbl:switches}. The status of all on-board switches can be
read from the board's status register (SR -- see Appendix~\ref{app:conv-regs-sr} and
Section~\ref{sec:diag-sw-rtmdet}).

\begin{figure}[htbp]
  \centerline{\includegraphics[scale=.65]{fig/switches}}
  \caption{Switches on the CONV-TTL-BLO board}
  \label{fig:switches}
\end{figure}

\begin{table}[htbp]
  \caption{Switches on CONV-TTL-BLO}
  \label{tbl:switches}
  \centerline
  {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{l p{.85\textwidth}}
    \hline
    \multicolumn{1}{c}{\textbf{Switch}} & \multicolumn{1}{c}{\textbf{Description}} \\
    \hline
    SW1.1 & Glitch filter enable (see Section~\ref{sec:pulse-jit}) \newline
            \textbf{ON} -- glitch filter enabled, output jitter present \newline
            \textbf{OFF} -- glitch filter disabled, no output jitter (default) \\
    SW2.4 & TTL/TTL-BAR selection switch (see Section~\ref{sec:pulse-ttl-vs-ttlbar}) \newline
            \textbf{ON} -- TTL channels receive and generate TTL (default) \newline
            \textbf{OFF} -- TTL channels receive and generate TTL-BAR \\
    \hline
    \end{tabular}
  }
\end{table}

Note that both switches in Table~\ref{tbl:switches} are board-wide switches; selecting
one position or the other yields a selection valid for all six pulse replication channels.

\textbf{\textit{It is recommended to not switch any of the switches while the board is plugged
into the crate, otherwise potential damage can be incurred to hardware components on the
board.}}

%======================================================================================
% SEC: Pulse replication
%======================================================================================
\pagebreak
\section{Pulse replication}
\label{sec:pulse}

%--------------------------------------------------------------------------------------
% SUBSEC: Pulse signal def
%--------------------------------------------------------------------------------------
\subsection{Pulse signal definition}
\label{sec:pulse-def}

Three pulse types are defined in the context of CONV-TTL-BLO, depending on signal amplitude,
rise and fall times; pulse widths and frequencies are the same. TTL and TTL-BAR pulses
are input and output on the front panel of the boards. TTL-BAR is essentially an inverted
version of TTL signals (see Section~\ref{sec:pulse-ttl-vs-ttlbar}). Blocking pulses
\cite{StandardBlocking} are differential signals and are input and output on the rear
panel (via a CONV-TTL-RTM).

The various characteristics of the pulse signals are defined in
Figure~\ref{fig:pulse-def} and outlined in Table~\ref{tbl:pulse-def-ttl} for
TTL and TTL-BAR pulses, and in Table~\ref{tbl:pulse-def-blo} for blocking
pulses.

\begin{figure}[h]
  \centerline{\includegraphics[width=\textwidth]{fig/pulse-def}}
  \caption{Pulse signal characteristics}
  \label{fig:pulse-def}
\end{figure}

\begin{table}[h]
  \caption{TTL and TTL-BAR pulse characteristics}
  \label{tbl:pulse-def-ttl}
  \centerline
  {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{l l c c c c}
    \hline
    \multicolumn{1}{c}{\textbf{Symbol}} & \multicolumn{1}{c}{\textbf{Parameter}} &
    \textbf{Min.} & \textbf{Typ.} & \textbf{Max.} & \textbf{Unit}\\
    \hline
    $V_{IH}$ & Input pulse high-level amplitude (1)(2) & 1   &     & 5.5 & V \\
    $V_{IL}$ & Input pulse low-level amplitude (2)     & 0.7 &     & 1.6 & V \\
    $V_{OH}$ & Output pulse high-level amplitude       & 2.4 & 3.3 &  5  & V \\
    $V_{OL}$ & Output pulse low-level amplitude        &     &  0  & 0.7 & V \\
    $t_{p,i}$& Input pulse width                       & 100 &     &     & ns  \\
    $t_{p,o}$& Output pulse width                      &     & 1.2 &     & ${\mu}s$ \\
    $T_{min}$& Period of pulse signal (3)              & 241 &     &     & ${\mu}s$ \\
    $t_r$    & Rise time                               &  1  & 3.2 & 4.9 & ns \\
    $t_f$    & Fall time                               &  2  &  4  & 5.6 & ns \\
    \hline
    \end{tabular}
  }
\end{table}

\noindent Note 1: Pulse amplitude for which a $t_{p,o}$ pulse is replicated at the output. \\
\noindent Note 2: $V_{IH}$, $V_{IL}$ correspond to the thresholds of input Schmitt triggers. \\
\noindent Note 3: Max. pulse frequency dictated by blocking output max. frequency and limited
by the FPGA gateware. \\

\pagebreak
\begin{table}[h]
  \caption{Blocking pulse characteristics}
  \label{tbl:pulse-def-blo}
  \centerline
  {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{l l c c c c}
    \hline
    \multicolumn{1}{c}{\textbf{Symbol}} & \multicolumn{1}{c}{\textbf{Parameter}} &
    \textbf{Min.} & \textbf{Typ.} & \textbf{Max.} & \textbf{Unit}\\
    \hline
    $V_{IH}$ & Input pulse high-level amplitude (1) & 3.8 &     &  25 & V \\
    $V_{IL}$ & Input pulse low-level amplitude      &  -5 &     &     & V \\
    $V_{OH}$ & Output pulse high-level amplitude (2)&  23 & 24  &  25 & V \\
    $V_{OL}$ & Output pulse low-level amplitude (2) &     & 0   &     & V \\
    $t_{p,i}$& Input pulse width                    & 100 &     & 3900& ns \\
    $t_{p,o}$& Output pulse width                   &     & 1.2 &     & ${\mu}s$ \\
    $T_{min}$& Period of pulse signal (3)           & 241 &     &     & ${\mu}s$ \\
    $t_r$    & Rise time                            &  75 & 140 & 225 & ns \\
    $t_f$    & Fall time                            &  75 & 160 & 225 & ns \\
    \hline
    \end{tabular}
  }
\end{table}

\noindent Note 1: Pulse amplitude for which a $t_{p,o}$ pulse is replicated at the output. \\
\noindent Note 2: Voltage amplitude between the differential signal lines. \\
\noindent Note 3: Max. pulse frequency dictated by blocking output max. frequency and limited
by the FPGA gateware. \\

%--------------------------------------------------------------------------------------
% SUBSEC: TTL vs TTL-BAR
%--------------------------------------------------------------------------------------
\subsection{TTL vs. TTL-BAR}
\label{sec:pulse-ttl-vs-ttlbar}

The two signal types that may be replicated on the front panel are TTL or TTL-BAR. As
Figure~\ref{fig:pulse-ttl-vs-ttlbar} shows, TTL-BAR is an inverted version of TTL.

Selection between these two signal types is done by means of the TTL selection switch,
SW2.4 (Figure~\ref{fig:switches-ttl}). When the switch is \textbf{ON} (default), TTL pulses
arriving on the front panel input or blocking pulses arriving on the rear panel input
are replicated to TTL pulses on the front panel. When the switch is \textbf{OFF},
TTL-BAR pulses arriving on the front panel or blocking pulses arriving on the rear panel
are replicated to TTL-BAR pulses on the front panel.

\begin{figure}[htbp]
  \centerline{\includegraphics[scale=.75]{fig/ttl-vs-ttlbar}}
  \caption{TTL and TTL-BAR signals}
  \label{fig:pulse-ttl-vs-ttlbar}
\end{figure}

\begin{figure}[htbp]
  \centerline{\includegraphics[scale=.75]{fig/switches-ttl}}
  \caption{TTL/TTL-BAR selection switch}
  \label{fig:switches-ttl}
\end{figure}

The TTL selection switch is valid board-wide, i.e., if it is set for TTL inputs (\textbf{ON}),
TTL signals should be input on all TTL channels. Due to the pulse replication mechanism (see
Section~\ref{sec:pulse-rep}), inputting TTL-BAR signals on a channel while the TTL/TTL-BAR
selection switch is set to TTL will lead to a delay of one pulse width. To avoid this
unwanted delay, it is therefore encouraged to pay attention to the status of this switch
before plugging the board into a crate.

%--------------------------------------------------------------------------------------
% SUBSEC: Rep details
%--------------------------------------------------------------------------------------
\subsection{Pulse replication mechanism}
\label{sec:pulse-rep}

Figure~\ref{fig:pulse-rep} shows a diagram of how pulses are replicated on a channel inside
the FPGA. The figure also shows the shape of the different types of pulse signals after they
pass through a part of the circuit. The grey DC signals are the signals when no wire is
plugged into a channel.

\begin{figure}[htbp]
  \centerline{\includegraphics[width=.95\textwidth]{fig/pulse-rep}}
  \caption{Pulse repetition mechanism}
  \label{fig:pulse-rep}
\end{figure}

The pulse generator (PG) block in the FPGA generates $t_{p,o}$ wide (Table~\ref{tbl:pulse-def-ttl})
TTL pulses at its output on the rising edge of its input. It therefore expects TTL pulses at
its input. Once a TTL pulse arrives at the input of the PG block, it extends this pulse (or cuts it)
to $t_{p,o}$ and then enters a rejection state, where no more pulses are accepted on the input. The
basic operation of the PG block is shown in Figure~\ref{fig:pg-op}. For more information
about the implementation of the PG block, refer to the CONV-TTL-BLO HDL Guide~\cite{ctb-hdlguide}.

\begin{figure}
  \centerline{\includegraphics[width=\textwidth]{fig/pg-op}}
  \caption{Pulse generator block operation}
  \label{fig:pg-op}
\end{figure}

The rest of the logic external to the PG block is used to accommodate for TTL-BAR
and blocking pulses. First, the OR gates at the PG input indicate the condition for a pulse to
be regenerated. The conditions for pulse generation are either that pulse is manually triggered
as described in Section~\ref{sec:diag-man-trig}, or that a pulse arrives on either of the inputs of a channel
(TTL or TTL-BAR on the front panel, or blocking on the rear panel).

On the blocking side, the voltage level of blocking pulses arriving on the RTM is adapted
to a voltage level suitable for the FPGA by on-board circuitry external to the FPGA.
What ends up in the FPGA is a TTL type pulse, so this may be passed directly
to the PG's input through the OR gate. The output of the PG block is passed to the FPGA
output and to the three blocking pulse outputs of a channel, where the blocking-level
pulse is generated.

On the TTL side, pulse signals go through a Schmitt trigger inverter buffer to the FPGA.
The termination resistor pulls the input line to ground when there is no signal, so
this gets inverted to $V_{cc}$ by the Schmitt trigger. Based on the setting of the
TTL switch (see Section~\ref{sec:pulse-ttl-vs-ttlbar}), the multiplexer assures a TTL
signal at the OR gate input.

The \textit{no signal detect} block at the multiplexer input on the TTL-BAR side
detects the lack of a signal by checking for a continuous high level on the line.
This is important when the TTL selection switch is set to TTL-BAR, since no signal
would mean a DC high-level signal appears at the OR gate input and this signal would
inhibit pulses arriving from the blocking side. The \textit{no signal detect} block
checks if the line is high for more than 100~$\mu$s when the TTL selection switch is
set for TTL-BAR signals and disables the TTL input line to the PG, thus allowing for
blocking pulses arriving on the rear panel to be detected by the PG.

After the two types of signals are ORed together to form a trigger to the PG block,
they can optionally be passed through a glitch filter (the GF block in Figure~\ref{fig:pulse-rep}).
More details about this glitch filter can be found in Section~\ref{sec:pulse-jit}.

One pulse counter is implemented for each channel. This pulse counter increments when a
rising edge is detected on the output of the OR gate between the two inputs types. More
details about the pulse counters can be found in Section~\ref{sec:diag-pulse-cnt}.

A rising edge on a pulse also triggers storing the value of a user-settable time tag to
a ring buffer memory. More details about the timetagging of pulses can be found in
Section~\ref{sec:diag-pulse-timetag}.

The PG block can also be triggered by a "manual" pulse. More details about this feature
can be found in Section~\ref{sec:diag-man-trig}.

\textbf{\textit{Note that due to the nature of TTL-BAR signals (high when idle), when the cable is removed
from the connector, or when the pulse sending device upstream of the CONV-TTL-BLO is turned off,
the channel line goes high due to the Schmitt trigger at the input of the CONV-TTL-BLO, and
a pulse will be generated on the output.}}

%--------------------------------------------------------------------------------------
% SUBSEC: Pulse jitter and delay
%--------------------------------------------------------------------------------------
\subsection{Pulse jitter and delay}
\label{sec:pulse-jit}

Figure~\ref{fig:tpd-jit} defines propagation delay from input to output (measured visually
using an oscilloscope with cursors placed on the signals as shown in the figure) and output
jitter. Table~\ref{tbl:pulse-tpd-jit} presents the characteristics measured on
the CONV-TTL-BLO.

The PG block incorporates a glitch filter that can prevent pulses being generated as a
result of a glitch occurring on input channels. The glitch filter can be enabled via
SW1.1 (Figure~\ref{fig:switches-ptype}).

\begin{figure}[htbp]
  \centerline{\includegraphics[scale=.7]{fig/switches-ptype}}
  \caption{Glitch filter enable switch}
  \label{fig:switches-ptype}
\end{figure}

Placing SW1.1 in the \textbf{ON} position will enable the glitch filter inside the PG block.
The pulse signal is sampled with a 20~MHz on-board clock and passed through the
glitch filter which rejects any pulses narrower than 50~ns, but introduces a 50~ns jitter
on the leading edge of the output signal. Jitter appears in the form of an uncertainty on when
a pulse is output.

Since an input pulse is asynchronous to the sampling clock, it may arrive
before or after the sampling clock's rising edge. If it arrives before the sampling clock rising
edge, it is sampled on the current cycle. However, if the input pulse arrives after the rising edge,
it will get sampled on the next clock rising edge. The output pulse may therefore present
an uncertainty on when its leading edge arrives; this uncertainty (shown in Figure~\ref{fig:tpd-jit}),
which is the output jitter, is based on the 50~ns sampling clock. 

When SW1.1 is in the \textbf{OFF} (default) position, the glitch filter is disabled and the
pulse signal is regenerated at the output without being sampled with an on-board clock. This
yields jitter-free pulses at the output, but a glitch on the input will lead to a pulse being
generated at the output.

The glitch filter internal to the PG block may be enabled when the environment where the
board operates is noisy. A noisy environment may lead to glitches induced on the
signal lines and thus unwanted pulses on the output of the CONV-TTL-BLO. When the
environment is not so noisy, or when the 50~ns jitter is deemed to be an issue, SW1.1
can be left in the \textbf{OFF} position.

\begin{figure}[h]
  \centerline{\includegraphics[width=\textwidth,keepaspectratio]{fig/tpd-jit}}
  \caption{Output pulse delay and jitter}
  \label{fig:tpd-jit}
\end{figure}

\pagebreak
\begin{table}[h]
  \caption{Output pulse delay and jitter}
  \label{tbl:pulse-tpd-jit}
  \centerline
  {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{l l c c}
    \hline
    \multicolumn{1}{c}{\textbf{Symbol}} & \multicolumn{1}{c}{\textbf{Parameter}} &
    \textbf{Value} & \textbf{Unit} \\
    \hline
    $t_j$    & Leading edge jitter                &     &    \\
             & \hspace{2mm} Without glitch filter & 0   & ns \\
             & \hspace{2mm} With glitch filter    & 50  & ns \\
    $t_{PD}$ & Propagation delay (1) (2)          &     &    \\
             & \hspace{2mm} TTL to TTL            & 40  & ns \\
             & \hspace{2mm} TTL to blocking       & 80  & ns \\
             & \hspace{2mm} Blocking to TTL       & 80  & ns \\
             & \hspace{2mm} TTL-BAR to TTL-BAR    & 50  & ns \\
             & \hspace{2mm} TTL-BAR to blocking   & 90  & ns \\
             & \hspace{2mm} Blocking to TTL-BAR   & 90  & ns \\
             & \hspace{2mm} Blocking to blocking  & 120 & ns \\
             & \hspace{2mm} Inverter channel      & 30  & ns \\
    \hline
    \end{tabular}
  }
\end{table}

\noindent Note 1: If the glitch filter is enabled, it adds an extra 350~ns delay to $t_{PD}$. \\
\noindent Note 2: Measured visually using cursors on an oscilloscope.

%======================================================================================
% SEC: Communicating to the CONV-TTL-BLO
%======================================================================================
\pagebreak
\section{Communicating with the CONV-TTL-BLO}
\label{sec:comm}

It is possible to communicate to the CONV-TTL-BLO remotely via the VME P1 I$^2$C interface.
This section describes how to connect to the VME64x crate and communicate to the board.

In order to connect to a CONV-TTL-BLO board in an ELMA VME crate, a higher-level
protocol based on I$^2$C is defined \cite{sysmon-i2c}. The protocol uses the serial
lines on the VME P1 connector (\textit{SERCLK}, \textit{SERDAT}).

By this protocol, 2$^{12}$ (12 address bits) 32-bit registers can be read from or written
to byte by byte. A complete memory map for accessible registers can be found in Appendix~\ref{app:memmap}.

The user can access the CONV-TTL-BLO registers via either Telnet or SNMP. First, a connection
is made to the VME crate using either of these two protocols. Then, based on the protocol, commands
are sent via Telnet, or SNMP-specific object identifiers (OID) in the case of SNMP. Both
of these means of connecting to the CONV-TTL-BLO are described in the following subsections.

All the examples below were tried on a Ubuntu Linux computer.

\begin{figure}[h]
  \centerline{\includegraphics[width=.8\textwidth]{fig/comm}}
  \caption{Communicating to the CONV-TTL-BLO FPGA}
  \label{fig:comm}
\end{figure}

%%--------------------------------------------------------------------------------------
%% SUBSEC: Telnet
%%--------------------------------------------------------------------------------------
\subsection{Telnet}
\label{sec:comm-telnet}

The first method to access registers on the CONV-TTL-BLO via the I$^2$C interface is via
a command-line based interface. This can be accessed via Telnet, through which commands
can be sent. Three Telnet commands (see Table~\ref{tbl:cmds}) can be used to transfer
data to the board. As  names suggest, \textit{readreg} reads a board register, whereas
\textit{writereg} and \textit{writemregs} write to a board register.

\begin{table}[h]
  \caption{Telnet commands to read and write registers}
  \label{tbl:cmds}
  \centerline
  {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{l p{.6\textwidth}}
    \hline
    \multicolumn{1}{c}{\textbf{Command}}   & \multicolumn{1}{c}{\textbf{Description}} \\
    \hline
    writereg \textit{slot addr val}        & Writes the \textit{hex} value \textit{val} to hex address
                                             \textit{addr} of board in slot number \textit{slot}. \\
    writemregs \textit{slot addr v1 .. v8} & Allows writing up to eight different values
                                             to the same register. The values are given in hexadecimal
                                             format and are separated by spaces.   \\
    readreg \textit{slot addr}             & Returns the value of register at hex address \textit{addr} of
                                             board in slot number \textit{slot}. \\
    \hline
    \end{tabular}
  }
\end{table}

An example of retrieving the CONV-TTL-BLO ID of a CONV-TTL-BLO plugged into VME slot 2 of the crate
\textit{some-crate} is given below. The converter board ID can be retrieved from the board ID
register at address \textbf{0x000} (BIDR -- see Appendix~\ref{app:conv-regs-bidr}),
if the board is present in slot 2, the command should yield the ASCII string \textbf{TBLO}.

\begin{verbatim}
tstana@tstana-unit:~$ telnet some-crate
Trying 137.138.192.90...
Connected to some-crate.cern.ch.
Escape character is '^]'.
login:user
password:**********
%>readreg 2 0
 Read Data: 54424C4F
%>
\end{verbatim}

First, a Telnet connection is made with the crate, after which the \textit{readreg} command is issued 
to read the value of address 0. The value of the register can be confirmed to be
the hex value of the ASCII string \textbf{TBLO}, so the board is indeed present in the slot.

Another example of running the same command, this time with the board removed from the crate, is given
below. As expected, when the board is removed, it can no longer acknowledge the I$^2$C access, thus the
message:

\begin{verbatim}
Connected to some-crate.cern.ch.
Escape character is '^]'.
login:user
password:**********
%>readreg 2 0
 Not Acknoledged!
%>
\end{verbatim}

An example of writing the value \textbf{0xabcde} to a register at address \textbf{0x1c4} of
a board in VME slot 11 and then reading it back to check for correct write is given below.
Note that this example does not normally yield a similar result if performed on the
CONV-TTL-BLO, since even if a register is implemented at address \textbf{0x1c4},
it may not be writable.

\begin{verbatim}
Connected to some-crate.cern.ch.
Escape character is '^]'.
login:user
password:**********
%>writereg 11 1c4 abcde
 Done!
%>readreg 11 1c4
 Read Data: 000ABCDE
\end{verbatim}

%------------------------------------------------------------------------------
% SUBSEC: SNMP
%------------------------------------------------------------------------------
\subsection{SNMP}
\label{sec:comm-snmp}

The second method to access the CONV-TTL-BLO board is via the Simple Network
Management Protocol (SNMP). ELMA crates offer a Management Information Base (MIB)
which provide access to various information such as voltage and current sensor
readout, fan speeds and information about VME slots. Among the information about
the VME slots one can access register values for both read and write.

In order to access the registers, SNMP \textit{Get} and \textit{Set} requests
should be sent to a specific OID. The OID, apart from the ELMA enterprise
identifier and other OIDs to parse the MIB object tree, the VME slot number and
register indexes that translate to specific register addresses on the board.

An example of retrieving the CONV-TTL-BLO board ID from a card placed into the same
\textit{some-crate} in slot 2 is given below.

Note that in this and other examples the backslash is not needed, it is just added
here for formatting reasons and to keep to the rules of the Linux command-line.

\begin{verbatim}
%> snmpget -v2c -c public some-crate \
   iso.3.6.1.4.1.37968.1.1.8.2.2.1.2.1
iso.3.6.1.4.1.37968.1.1.8.2.2.1.2.1 = STRING: "54424C4F"
\end{verbatim}

Here, the \textit{snmpget} command is used with a version 2c SNMP protocol (the
\textit{-v} parameter) and using the public community string (the \textit{-c} parameter).
The OID (the last parameter of the \textit{snmpget} command) contains multiple
values that inform the MIB compiler how to parse the MIB object tree. Of these
values, only two are relevant to the user. These values are presented in
Figure~\ref{fig:oid}.

\begin{figure}[h]
  \centerline{\includegraphics[width=\textwidth]{fig/oid}}
  \caption{Relevant figures in the SNMP OID}
  \label{fig:oid}
\end{figure}

To obtain register index values from register addresses as specified in
Appendix~\ref{app:memmap}, the following formula should be used:

\begin{center}
$reg. index = \frac{addr}{4} + 1$
\end{center}

To perform a write to a register via SNMP, the admin password of the crate
should be known.

An example of writing the value \textbf{0xabcde} to a register
at address \textbf{0x1c4} of a board in VME slot 11 and then reading it back to
check for correct write is given below. Note that this example does not normally
yield a similar result if performed on the CONV-TTL-BLO, since even if a register
is implemented at address \textbf{0x1c4}, it may not be writable.

\begin{verbatim}
%> snmpset -v2c -c admin-password some-crate \
   iso.3.6.1.4.1.37968.1.1.8.11.2.1.2.114 s abcde
iso.3.6.1.4.1.37968.1.1.8.2.2.1.2.114 = STRING: "abcde"
%> snmpget -v2c -c public some-crate \
   iso.3.6.1.4.1.37968.1.1.8.11.2.1.2.114
iso.3.6.1.4.1.37968.1.1.8.2.2.1.2.114 = STRING: "000ABCDE"
\end{verbatim}

%%--------------------------------------------------------------------------------------
%% SUBSEC: Comm timeout
%%--------------------------------------------------------------------------------------
\subsection{Communication timeout}
\label{sec:comm-timeout}

The CONV-TTL-RS485 FPGA implements an I$^2$C slave that decodes the protocol
to access the registers. The I$^2$C slave also implements a watchdog timer that
resets the slave logic if the communication takes too long to complete.

Currently, the timeout is set to 24~ms. Should the timeout occur, a system error bit is set
in the board status register (see Section~\ref{sec:diag-syserr}) and the
\textit{ERR} bicolor LED is lit red.

%==============================================================================
% SEC: Diagonstics
%==============================================================================
\pagebreak
\section{Diagnostics}
\label{sec:diag}

This section details the remote diagnostics features implemented via the logic
inside the FPGA on-board the CONV-TTL-BLO. Diagnostics data about a CONV-TTL-BLO
can be obtained via the I$^2$C interface detailed in Section~\ref{sec:comm}.

The following diagnostics features are implemented on the CONV-TTL-BLO:

\begin{itemize}
  \item converter board identification
  \item reading the unique board ID and temperature
  \item reading of the FPGA gateware version
  \item reading the state of the on-board switches
  \item reading the state of the RTM detection lines
  \item input pulse counters
  \item input pulse time-tagging
  \item remotely reset the FPGA logic
  \item manually trigger a pulse
\end{itemize}

Most of the diagnostics features below have test scripts implemented in the
main project repository~\cite{ctb-repo}. These test scripts can be found in the
\textit{software/diag/} folder. Section~\ref{sec:repo} provides more details
about the project repository.

%------------------------------------------------------------------------------
% SUBSEC: Board ID
%------------------------------------------------------------------------------
\subsection{Converter board identification}
\label{sec:diag-bid}

All converter boards have a board identification register (BIDR -- see
Appendix~\ref{app:conv-regs-bidr}) at address \textbf{0x000}. This register is
a read-only 32-bit register containing the hex values for the ASCII code
describing the functionality of the converter board.

In the case of the CONV-TTL-BLO, the BIDR contains the ASCII string \textbf{TBLO},
for TTL-to-blocking converter.

%------------------------------------------------------------------------------
% SUBSEC: FPGA gateware version
%------------------------------------------------------------------------------
\subsection{FPGA gateware version}
\label{sec:diag-gwvers}

The gateware version can be read from the least significant eight bits of the
status register (SR -- see Appendix~\ref{app:conv-regs-sr}). The gateware version
is split into major and minor version numbers. Both numbers are decimal numbers.
The major version number increments on major changes in the gateware, such as
the implementation of new blocks. The minor version increments on bug fixes.

%------------------------------------------------------------------------------
% SUBSEC: Thermo, unique ID
%------------------------------------------------------------------------------
\subsection{Unique board ID and temperature readout}
\label{sec:diag-id-therm}

\begin{tabular}{p{.96\textwidth}}
\hline
\large \hspace*{22pt} Not implemented in golden gateware versions \\
\hline
\end{tabular}

\vspace*{11pt}

CONV-TTL-BLO boards contain a thermometer chip~\cite{ds18b20} which can be used to read the
board temperature. This thermometer chip is also factory-programmed with a unique
ID which can be used to uniquely identify a CONV-TTL-BLO.

To access this thermometer, the CONV-TTL-BLO uses a 1-wire interface~\cite{onewire-tech}.
The thermometer is a one-wire slave and the FPGA on-board the CONV-TTL-BLO is
a one-wire master in the communication. To access and control this interface,
a memory-mapped one-wire master core~\cite{onewire-core} is implemented on the
FPGA, as shown in Figure~\ref{fig:onewire}.

\begin{figure}[h]
  \centerline{\includegraphics[width=.9\textwidth]{fig/onewire}}
  \caption{Interface to the one-wire thermometer}
  \label{fig:onewire}
\end{figure}

Data from the thermometer can be obtained one bit at a time by controlling
the one-wire master core as described in its specification manual~\cite{onewire-core}.
Relevant data in the thermometer are listed in Table~\ref{tbl:thermo-data}. More
details about this data and how to obtain it can be found in the device's
datasheet~\cite{ds18b20}.

Note that an example Python script is provided in the \textit{software/diag/} folder
of the main project repository~\cite{ctb-repo}. Section~\ref{sec:repo-software}
gives more details about the test scripts in the project repository.

\begin{table}[h]
  \caption{Data from thermometer}
  \label{tbl:thermo-data}
  \centerline
  {
  \rowcolors{2}{white}{gray!25}
  \begin{tabular}{l l p{.7\textwidth}}
  \hline
  \multicolumn{1}{c}{\textbf{Data}} & \multicolumn{1}{c}{\textbf{Length}} & 
  \multicolumn{1}{c}{\textbf{Description}} \\
  \hline
  ID & 48 bits & Unique ID, packed within 64 bits \\
  Temp.     & 16 bits & Current temperature, multiple resolutions available \\
  CRC       & 8 bits  & CRC for the unique ID and temperature data \newline
                        The FPGA logic does not interpret the CRC \\
  \hline
  \end{tabular}
  }
\end{table}

%------------------------------------------------------------------------------
% SUBSEC: RTM lines and on-board switches
%------------------------------------------------------------------------------
\subsection{On-board switches and RTM lines}
\label{sec:diag-sw-rtmdet}

The state of the on-board switches and that of the RTM detection lines can
also be read from the SR (see Appendix~\ref{app:conv-regs-sr}).

In the case of the switches, the raw state of the FPGA inputs is reflected on
the SR bits (Figure~\ref{fig:sr-switches}). Since an ON switch pulls the line to GND, a '0' value on one
of the switch bits means the switch is on. 

In the case of the RTM detection lines~\cite{rtm-det}, the lines reflect the
actual status of the RTM detection line, prior to it being inverted on the board
(Figure~\ref{fig:rtm-det}). So, if an RTM detection line is \textit{Open}, its
state in the SR will be a logic '1', and if it is pulled low by an RTMM/P, its
state in the SR will be a logic '0'.

\begin{figure}
  \centerline{\includegraphics[width=.5\textwidth]{fig/sr-switches}}
  \caption{Switch mapping to the SR}
  \label{fig:sr-switches}
\end{figure}

\begin{figure}
  \centerline{\includegraphics[width=.85\textwidth]{fig/rtm-det}}
  \caption{RTM detection lines to status register}
  \label{fig:rtm-det}
\end{figure}

%------------------------------------------------------------------------------
% SUBSEC: Pulse counters
%------------------------------------------------------------------------------
\subsection{Pulse counters}
\label{sec:diag-pulse-cnt}

\begin{tabular}{p{.96\textwidth}}
\hline
\large \hspace*{22pt} Not implemented in golden gateware versions \\
\hline
\end{tabular}

\vspace*{11pt}

One channel is allocated on the input of each counter, after the OR gate preceding
the pulse generator. The input counter logic, which is repeated on each channel,
is shown in Figure~\ref{fig:pulse-cnt}. On a rising edge of a pulse from either a
TTL or a blocking input, the pulse counter is incremented and stored to the channel's
pulse counter register (CHxPCR -- see Appendix~\ref{app:conv-regs}). The CHxPCR is a
read-write register that can be written at any time via I$^2$C with a user-defined value.

\begin{figure}[h]
  \centerline{\includegraphics[width=\textwidth]{fig/pulse-cnt}}
  \caption{Channel pulse counter diagram}
  \label{fig:pulse-cnt}
\end{figure}

%------------------------------------------------------------------------------
% SUBSEC: Pulse counters
%------------------------------------------------------------------------------
\subsection{Pulse time-tagging}
\label{sec:diag-pulse-timetag}

\begin{tabular}{p{.96\textwidth}}
\hline
\large \hspace*{22pt} Not implemented in golden gateware versions \\
\hline
\end{tabular}

\vspace*{11pt}

The architecture of the time-tagging mechanism is shown in Figure~\ref{fig:timetag-arch}.

\begin{figure}[h]
  \centerline{\includegraphics[width=\textwidth]{fig/timetag-arch}}
  \caption{Time-tagging architecture}
  \label{fig:timetag-arch}
\end{figure}

Every time a pulse arrives on a channel, a timetag sample is stored to a 128-deep
ring buffer. While this ring buffer is not entirely accessible in the addressing
space of the FPGA, it can be read sample by sample by reading the TBCYR, TBL/HR and
TBMR registers (see Appendix~\ref{app:conv-regs}). At the same time the timestamp is
stored into the time-tag buffer, it is also stored to the latest timestamp registers
(CHxLTS*R -- see Appendix~\ref{app:conv-regs}).

%------------------------------------------------------------------------------
\subsubsection{Pulse timetags}
%------------------------------------------------------------------------------

Two timetags are available on the CONV-TTL-BLO. These timetags are listed in
Table~\ref{tbl:timetags}. When White-Rabbit (WR) is present, the precise centralized
and synchronized timing from the WR network is used. When WR is not present, the local
time tag is used. Note that due to the fact that this timetag is unsynchronized,
it will differ slightly between two different boards in a crate. Each timetag sample
consists of a cycles value, which counts 8~ns cycles, and a TAI seconds value.

\begin{table}[h]
  \caption{Timetag types}
  \label{tbl:timetags}
  \centerline
  {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{l c p{.65\textwidth}}
      \hline
      \multicolumn{1}{c}{\textbf{Type}} & \multicolumn{1}{c}{\textbf{Resolution}}
      & \multicolumn{1}{c}{\textbf{Description}} \\
      \hline
      WR    & 8~ns & \textbf{\textit{Currently not implemented}} \newline
                     Precise, centralized and synchronized timetag \newline
                     Obtained and configurable via WR \\
      Local & 8~ns & Local, unsynchronized timetag \newline
                     Obtained by counting the ticks of a 125~MHz clock signal \newline
                     Configurable by writing the TAI value registers (TVL/HR) \\
      \hline
    \end{tabular}  
  }
\end{table}

%------------------------------------------------------------------------------
\pagebreak
\subsubsection{Timetag storage delay}
%------------------------------------------------------------------------------

Due to the internal logic of the FPGA, there is a delay of three to four 8~ns cycles
between the moment when a pulse arrives on the channel input and the moment when
a timetag is stored to the ring buffer. This delay is shown in Figure~\ref{fig:timetag-delay}.

\begin{figure}[h]
  \centerline{\includegraphics[width=.8\textwidth]{fig/timetag-delay}}
  \caption{Timetag storage delay}
  \label{fig:timetag-delay}
\end{figure}

%------------------------------------------------------------------------------
\subsubsection{Reading the timetags from the ring buffer}
%------------------------------------------------------------------------------

The TBCYR, TBTLR and TBTHR (see Appendix~\ref{app:conv-regs}) contain the actual
timetag values; the TBMR qualifies these timetag values with meta data such as
which channel triggered the timetag sample and whether a timestamp comes from WR
or from the local timer.

These registers always point to the oldest timetag in the ring buffer, and
reading them returns subsequent timetags in the buffer.

In order to obtain the correct timetags from the ring buffer, the read sequence
shown in Table~\ref{tbl:timetag-rd-seq} should be performed. This sequence should be
performed as long as the buffer is not empty (the first step is true).

For more details on the ring buffer, see the next subsection.

\setcounter{rownr}{0}

\begin{table}[h]
  \caption{Timetag read sequence}
  \label{tbl:timetag-rd-seq}
  \centerline {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{c p{.8\textwidth}}
    \hline
    \textbf{Step} & \multicolumn{1}{c}{\textbf{Action}} \\
    \hline
    \rownumber & \textbf{Read the TBCSR} and make sure that the EMPTY bit is not '1' \\
    \rownumber & \textbf{Read the TBCYR} to obtain the 8~ns cycles counter value \\
    \rownumber & \textbf{Read the TBTLR} to obtain the lower part of the TAI seconds counter \\
    \rownumber & \textbf{Read the TBTHR} to obtain the upper part of the TAI seconds counter \\
    \rownumber & \textbf{Read the TBTMR} to obtain the meta data about the timetag sample and advance
                 the buffer read pointer \\
    \hline
    \end{tabular}
  }
\end{table}

%------------------------------------------------------------------------------
\subsubsection{Ring buffer mechanics}
%------------------------------------------------------------------------------

The 128-deep ring buffer implemented in the FPGA gateware contains a read and a write
pointer, each of which advances on a read from and respectively a write to the buffer.
If the buffer is not empty, the read pointer points to the oldest timetag stored in the
buffer, while the write pointer points to the next buffer location to be written.

Figure~\ref{fig:timetag-buf-mech} shows the operation of the ring buffer.

\begin{figure}
  \centerline{\includegraphics[width=\textwidth]{fig/timetag-buf-mech}}
  \caption{Ring buffer mechanics, example with four-sample-deep buffer}
  \label{fig:timetag-buf-mech}
\end{figure}

Every time a pulse arrives on an input channel, a timetag is stored to the ring buffer
and the write pointer of the ring buffer is advanced.

When the write pointer reaches the read pointer, the buffer is full and subsequent writes
will overwrite previously written data, while the read pointer is advanced together with
the write pointer.

To read from the buffer, the user reads the TBCYR, TBTLR, TBTHR and TBMR (see Appendix~\ref{app:conv-regs}).
Reading the TBTMR register advances the read pointer of the buffer, if the buffer is not empty. If the
buffer is empty, the read pointer of the buffer is not advanced.

Note that due to the fact that a read from the TBMR advances the read pointer, the TBMR
should be the last register read in a read sequence. Otherwise, the read pointer is advanced
and the contents of the TBMR will correspond to one sample in the ring buffer, while
the contents of the TBCYR and TBH/LR will be that of another sample.

The TBCSR (see Appendix~\ref{app:conv-regs-tbcsr}) contains bits that allow to check the
status and clear the buffer. The USEDW field in this register contains the current number
of samples written to the buffer. When the buffer is full, the USEDW field is 0 and the 
FULL bit is set. Setting the CLR bit of the TBCSR will bring the read and write pointers
to 0 and set the USEDW field to 0.

%------------------------------------------------------------------------------
\subsubsection{Latest timestamp registers}
%------------------------------------------------------------------------------

There are three registers per channel dedicated to the storage of the latest timestamp.
These registers always store the latest time at which a pulse arrived on a channel and
can be useful when other channels fill up the ring buffer before a relevant timestamp
is read.

The memory map contains further details about the contents of each register
(see Appendix~\ref{app:conv-regs-ch1ltscyr} through~\ref{app:conv-regs-ch6ltsthr}).

%------------------------------------------------------------------------------
% SUBSEC: Remote reset
%------------------------------------------------------------------------------
\subsection{Remote reset}
\label{sec:diag-remote-reset}

The user can remotely reset the FPGA logic inside the CONV-TTL-BLO by writing to
the board's control register at address \textbf{0x008} (see Appendix~\ref{app:conv-regs-cr})
to first unlock the RST bit and then write it high to initiate the reset. When the
reset is initiated, a 100~ms reset pulse is applied to the logic.

An example of resetting a card in slot 11 using the Telnet commands is given below.

\begin{verbatim}
%>writereg 11 8 1
 Done!
%>writereg 11 8 2
 Not acknoledged!
\end{verbatim}

A remote reset will also reset the I$^2$C interface logic, hence the
\textit{Not acknowledged} response above. After the reset period of 100~ms, during
which all FPGA logic is reset, the user will be able to communicate to the
CONV-TTL-BLO board again.

Using SNMP, the commands outlined below should be issued to reset the card. Note that
the reply in the case of \textit{snmpset} is not as in the case of the Telnet
commands.

\begin{verbatim}
%> snmpset -v2c -c admin-password some-crate \
   iso.3.6.1.4.1.37968.1.1.8.2.2.1.2.3 s 1
iso.3.6.1.4.1.37968.1.1.8.2.2.1.2.3 = STRING: "1"
%> snmpset -v2c -c admin-password some-crate \
   iso.3.6.1.4.1.37968.1.1.8.2.2.1.2.3 s 2
iso.3.6.1.4.1.37968.1.1.8.2.2.1.2.3 = STRING: "2"
\end{verbatim}

Note that the backslash in the command above is not needed, it is just added
here for formatting reasons and to keep to the rules of the Linux command-line.

%------------------------------------------------------------------------------
% SUBSEC: Manual trigger
%------------------------------------------------------------------------------
\subsection{Manual pulse triggering}
\label{sec:diag-man-trig}

\begin{tabular}{p{.96\textwidth}}
\hline
\large \hspace*{22pt} Not implemented in golden gateware versions \\
\hline
\end{tabular}

\vspace*{11pt}

It is possible to remotely trigger a pulse on a channel of choice. This feature
should only be used when debugging the connection between two CONV-TTL-BLO boards,
or between a CONV-TTL-BLO and another receiver. This is why manual pulse
triggering is password-protected.

\begin{figure}[h]
  \centerline{\includegraphics[width=\textwidth]{fig/cr-mpt}}
  \caption{MPT field in the CR}
  \label{fig:cr-mpt}
\end{figure}

\begin{table}[h]
  \caption{Write sequence to initiate manual pulse triggering}
  \label{tbl:man-trig}
  \centerline
  {
    %\rowcolors{2}{white}{gray!25}
    \begin{tabular}{c c c c c}
      \hline
      \textbf{Byte 0} & \textbf{Byte 1} & \textbf{Byte 2} & \textbf{Byte 3} & \textbf{Byte 4}\\
      \hline
      0xde & 0xad & 0xbe & 0xef & Channel number in range 1..6 \\
      \hline
    \end{tabular}
  }
\end{table}

In order to manually trigger a pulse, the user should write five bytes to the board's control
register at address \textbf{0x004} (CR -- see Appendix~\ref{app:conv-regs-cr}), as shown in
Table~\ref{tbl:man-trig}. The MPT field is dual-purpose, as shown in
Figure~\ref{fig:cr-mpt}. Until the magic sequence is input, it should be written with the
bytes in the magic sequence. After that, it should be written with the channel number.

Figure~\ref{fig:man-trig-fsm} shows the manual pulse triggering logic. In order for a
pulse to be triggered, five write cycles to the MPT field must be done. If the fifth cycle is
a channel number in the range 1..6, one and only one pulse is generated by the PG
block (see Figure~\ref{fig:pulse-rep}). After that, should it be desired to generate
another pulse on the channel, the magic sequence must be input again. If the channel
number is not in the range 1..6, no pulse is generated on any channel and no
error is reported.

\begin{figure}[h]
  \centerline{\includegraphics[width=.6\textwidth]{fig/man-trig-fsm}}
  \caption{Manual pulse triggering logic}
  \label{fig:man-trig-fsm}
\end{figure}

%------------------------------------------------------------------------------
% SUBSEC: System Errors
%------------------------------------------------------------------------------
\pagebreak
\subsection{System errors}
\label{sec:diag-syserr}

\begin{tabular}{p{.96\textwidth}}
\hline
\large \hspace*{22pt} Not implemented in golden gateware versions \textit{older than v0.2} \\
\hline
\end{tabular}

\vspace*{11pt}

Various system errors are defined on converter boards. When such an error occurs,
the ERR LED on the front panel lights up in \textit{red}. At this point, the user
should connect to the converter board (Section~\ref{sec:comm}) to see exactly what
caused the system error.

The system errors defined for the CONV-TTL-BLO, together with the relevant bits
set when the error occurs, are shown in Table~\ref{tbl:syserr}.

\begin{table}[h]
  \caption{\label{tbl:syserr} System errors on the CONV-TTL-BLO}
  \centerline
  {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{p{.25\textwidth} l p{.5\textwidth}}
    \hline
    \multicolumn{1}{c}{\textbf{Error}} & \multicolumn{1}{c}{\textbf{Register}} &
    \multicolumn{1}{c}{\textbf{Description}} \\
    \hline
    Fallback to golden bitstream & SR.GWVERS & Error when booting from application bitstream,
                                               fallback to golden bitstream occured
                                               (see Section~\ref{sec:reprog-bitstreams}) \\
    I$^2$C timeout & SR.I2C\_WDTO & An I$^2$C transfer is not completed
                                    within 24~ms (see Section~\ref{sec:comm-timeout}) \\
    I$^2$C error & SR.I2C\_ERR & Attempted to access a non-memory-mapped address via I$^2$C \\
    Missed pulse & SR.PMISSE & Input pulse rejected (see Figure~\ref{fig:pg-op}) \\
    \hline
    \end{tabular}
  }
\end{table}

%------------------------------------------------------------------------------
% SUBSEC: LSR
%------------------------------------------------------------------------------
\pagebreak
\subsection{Line state readout}
\label{sec:diag-line-stat}

\begin{tabular}{p{.96\textwidth}}
\hline
\large \hspace*{28pt} Not implemented in gateware versions \textit{older than v3.0} \\
\hline
\end{tabular}

\vspace*{11pt}

The line status register (LSR -- see Appendix~\ref{app:conv-regs-lsr}) contains bits
that show the state of the channel line at the board input. Figure~\ref{fig:line-stat}
shows a diagram of this mapping, from the board input, through the on-board circuitry,
to the LSR.

Note that while in TTL-BAR repetition mode, the state \textit{no signal detect} block
(see Section~\ref{sec:pulse-rep}) is reflected in the FRONTFS bits of the LSR, effectively
showing if a cable is plugged in or not. While in TTL repetition mode, the FRONTFS bits in the LSR
are unused.

\begin{figure}[h]
  \centerline{\includegraphics[width=.95\textwidth]{fig/line-stat}}
  \caption{\label{fig:line-stat} Readout of line state at board input}
\end{figure}

%==============================================================================
% SEC: Remote reprog
%==============================================================================
\pagebreak
\section{Remote reprogramming support}
\label{sec:reprog}

CONV-TTL-BLO offer the capability of being reprogrammed from a remote PC. The user
sends the new FPGA bitstream via the I$^2$C interface to the CONV-TTL-BLO. The
on-board FPGA implements a remote reprogramming (also called MultiBoot) module, which
handles writing the bitstream to the on-board flash chip. After the bitstream has been
sent to the FPGA, the user issues an instruction (called the IPROG instruction) to the
FPGA. This instructs the FPGA to delete its configuration logic and reconfigure
itself with the new bitstream from the flash chip. All these steps are performed
by the user by writing to memory-mapped registers on the CONV-TTL-BLO.

%%--------------------------------------------------------------------------------------
%% SUBSEC: MultiBoot basics
%%--------------------------------------------------------------------------------------
%\subsection{MultiBoot basics}
%\label{sec:reprog-multiboot}
%
%MultiBoot~\cite{ug380} works by uploading multiple bitstreams into the external flash
%chip on-board the CONV-TTL-BLO. The concept is shown in Figure~\ref{fig:multiboot}.
%
%\begin{figure}[h]
%  \centerline{\includegraphics[scale=.4]{fig/multiboot}}
%  \label{fig:multiboot}
%  \caption{MultiBoot concept}
%\end{figure}
%
%When the board is powered-up, the CONV-TTL-BLO FPGA attempts to load itself from the
%attached flash chip, starting from address 0. This is where a small bitstream called the
%Header bitstream is located. The Header bitstream instructs the FPGA to configure itself
%from the MultiBoot bitstream. If this MultiBoot bitstream fails three times, the logic
%reverts to a Golden bitstream, which is known to be safe in case an error occurs while
%sending the MultiBoot bitstream. If for some reason, the Golden bitstream is corrupted,
%it is attempted three times, prior to falling back to the Header bitstream. While on
%the Header bitstream, the FPGA configuration logic attempts to load the MultiBoot and
%Golden bitstreams three more times, prior to halting configuration.
%
%A strike count internal to the FPGA configuration logic is used to implement this behavior.
%Bitstreams are selected based on this strike count as follows:
%
%\begin{itemize}
%  \item if it is 0..2, the MultiBoot bitstream gets loaded
%  \item if it is 3..5, the Golden bitstream gets loaded
%  \item if it is 6..8, the Header bitstream gets loaded, and MultiBoot and Golden
%  bitstreams are attempted three more times
%  \item if it is 9, configuration is halted
%\end{itemize}
%
%Note that the strike count can only be reset by power-cycling the CONV-TTL-BLO. Once
%a MultiBoot load has failed three times, the Golden bitstream will get loaded. This
%will happen even if a new and correct MultiBoot bitstream is uploaded to the flash,
%and the IPROG command is issued.

%--------------------------------------------------------------------------------------
% SUBSEC: Workflow
%--------------------------------------------------------------------------------------
\subsection{Workflow}
\label{sec:reprog-workflow}

The workflow for remote reprogramming is shown in Table~\ref{tbl:reprog-workflow}.

\setcounter{rownr}{0}

\begin{table}[h]
  \caption{MultiBoot workflow}
  \label{tbl:reprog-workflow}
  \centerline {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{c p{.7\textwidth}}
    \hline
    \textbf{Step} & \multicolumn{1}{c}{\textbf{Action}} \\
    \hline
    \rownumber & Prepare a Xilinx FPGA bitstream                                         \\
    \rownumber & Send the bitstream to the flash by writing to the FAR register          \\
    \rownumber & Write the MultiBoot bitstream start address and flash chip read command
                 op-code into the MBBAR register                                         \\
    \rownumber & Write the Golden bitstream start address and flash chip read command
                 op-code into the GBBAR register                                         \\
    \rownumber & Unlock the IPROG bit in the FPGA by setting CR.IPROG\_UNLOCK               \\
    \rownumber & Issue a reprogramming command to the FPGA by setting CR.IPROG           \\
    \rownumber & Check that reprogramming succeeded by checking that the GWVERS field
    				 in the SR corresponds to the gateware version of the written bitstream \\
    \hline
    \end{tabular}
  }
\end{table}

%--------------------------------------------------------------------------------------
% SUBSEC: Bitstreams
%--------------------------------------------------------------------------------------
\subsection{FPGA bitstreams on the CONV-TTL-BLO}
\label{sec:reprog-bitstreams}

The FPGA on-board the CONV-TTL-BLO is configured by bitstreams downloaded from the
on-board flash chip. There are two bitstreams relevant to the user.

The first is the application bitstream, which is the bitstream that runs when the
card is powered up. It is also the bitstream that the user loads to the
CONV-TTL-BLO flash when using remote reprogramming.

The second bitstream is the Golden bitstream, which is a bitstream known to be safe in
case something goes wrong when writing the application bitstream to the flash. This
bitstream contains the basic logic for pulse replication according to
section~\ref{sec:pulse-def}, as well as remote reprogramming. This means that the cards
can still be used for basic pulse repetition, as well as to load a new application
bitstream.

Note however that if the FPGA falls back to this Golden bitstream, even
if a new application bitstream is correctly loaded to the CONV-TTL-BLO flash chip,
a power-cycle will be needed to run this new bitstream.

To detect which bitstream is currently running, read the GWVERS field in the
board's status register (SR -- see Appendix~\ref{app:conv-regs-sr}).


%--------------------------------------------------------------------------------------
% SUBSEC: Flash memmap
%--------------------------------------------------------------------------------------
\subsection{Flash memory map}
\label{sec:reprog-flash-memmap}

The memory map for the CONV-TTL-BLO 32-Mbit on-board flash chip can be found in
Table~\ref{tbl:reprog-flash-memmap}.

\begin{table}[h]
  \caption{Flash memory map}
  \label{tbl:reprog-flash-memmap}
  \centerline{
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{l l l l}
    \hline
    \multicolumn{3}{c}{\textbf{Address}} & \multicolumn{1}{c}{\textbf{Description}} \\
    \hline
    0x000000 & -- & 0x000043 & Header bitstream                         \\
    0x000044 & -- & 0x16{}f{}f{}f{}f & Golden bitstream                         \\
    0x170000 & -- & 0x2d{}f{}f{}f{}f & MultiBoot bitstream                      \\
    0x2e0000 & -- & 0x3f{}f{}f{}f{}f & User non-volatile memory                 \\
    \hline
    \end{tabular}
  }
\end{table}

Of the available four megabytes of non-volatile memory, three are used for storing the
bitstreams. The remaining one megabyte is available to the user to store custom application
data. The user can access this space via the FAR register. Note that in order to write
data to the flash, a special sequence of commands should be sent. The flash write sequence
is given in the datasheet of the flash chip~\cite{m25p32}.

%--------------------------------------------------------------------------------------
% SUBSEC: Example script
%--------------------------------------------------------------------------------------
\subsection{The \textit{multiboot.py} script}
\label{sec:reprog-example-script}

An example Python script is provided to access the MultiBoot logic on the CONV-TTL-BLO.
The script can be found under the \textit{software/multiboot/} folder in the project
repository  (see Section~\ref{sec:repo}). The script implements the workflow in
Table~\ref{tbl:reprog-workflow} and can be used either as \textit{the} means of remotely
reprogramming the flash chip, or as an example for users to write their own tools.

The \textit{multiboot.py} script communicates to the reprogramming logic on the FPGA,
giving the user access to the following:

\begin{itemize}
  \item Readout of FPGA configuration register values (see the Configuration Registers
  section in \cite{ug380} and the \textit{xil\_multiboot} module documentation)
  \item Reading the first page of the flash starting with an address input by the user
  \item Writing a bitstream to the M25P32 flash chip
  \item Sending the IPROG command
\end{itemize}

More details about the script and how to run it can be found in the \textbf{README.txt}
file in the project repository.

%--------------------------------------------------------------------------------------
% SUBSEC: Don't program bitstreams w/o the ICAP
%--------------------------------------------------------------------------------------
\subsection{Important note regarding remote reprogramming}
\label{sec:reprog-imp-note}

Users should make sure that the new bitstream they program to the flash chip includes
the remote reprogramming module. Otherwise, once a bitstream without this module
inside it is loaded into the FPGA, the remote reprogramming capability of the FPGA is
lost, and the user will need to use JTAG or other means to program the FPGA with a
MultiBoot-enabled design.

%Thus, unless you are absolutely sure the bitstream without MultiBoot support is better
%than the Golden bitstream, always make sure the MultiBoot module is included in any bitstream
%generated after the Golden bitstream.

%======================================================================================
% SEC: Proj repo
%======================================================================================
\pagebreak

\section{Project repository}
\label{sec:repo}

All source files for the CONV-TTL-BLO board can be found in the form of an OHWR~\cite{ohwr}
\textit{git} repository. This repository can be obtained by running the following command:

\begin{small}
\begin{center}
\verb+git clone --depth=1 git://ohwr.org/level-conversion/conv-ttl-blo.git+
\end{center}
\end{small}

The folder structure of the repository is presented in Table~\ref{tbl:fold-struct}.

\begin{table}[h]
  \caption{Repository folder structure}
  \label{tbl:fold-struct}
  \centerline
  {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{l p{.7\textwidth}}
    \hline
    \multicolumn{1}{c}{\textbf{Folder}} & \multicolumn{1}{c}{\textbf{Description}} \\
    \hline
    \textit{conv-ttl-blo-gw/} & \textit{git} subproject for the FPGA gateware \\
    \textit{doc/}             & CONV-TTL-BLO board documentation, including this user guide \\
    \textit{pcb/}             & Source files for the latest version of the CONV-TTL-BLO
                                printed circuit boards \\
    \textit{software/}        & Tools that can be used to communicate to the CONV-TTL-BLO
                                and perform various functionality \\
    \hline
    \end{tabular}
  }
\end{table}


\subsection{Software tools}
\label{sec:repo-software}

At the time of writing of this document, the tools present in the \textit{software/}
repository are implemented in Python. They communicate to the CONV-TTL-BLO via Telnet
commands to read and write registers (see Section~\ref{sec:comm-telnet}). Most of these
tools use common Python modules to open up the Telnet connection and read and write the
registers. These common scripts can be found in the \textit{software/ei2c/} folder.

The \textbf{README.txt} files in each of the sub-folders of the \textit{software/} folder
contain the the most up-to-date information on the available test scripts. Other than that,
the source c.ode in the test scripts themselves provide the documentation for these software
tools.

\subsection{Raw bitstream files}

There is also the possibility of obtaining raw bitstream files corresponding to the various
versions of the FPGA gateware. The user can find the bitstream files by following the appropriate
link for the sought gateware version on the OHWR gateware releases webpage for the
CONV-TTL-BLO~\cite{ctb-gw-releases}.

%======================================================================================
% Appendices
%======================================================================================
\pagebreak

\begin{appendices}

%======================================================================================
% APP: Getting started
%======================================================================================
\section{Getting started with the CONV-TTL-BLO}
\label{app:get-started}

\begin{enumerate}
  \item Plug in the CONV-TTL-RTM board into the rear part of the VME crate.
  \item Remove the CONV-TTL-BLO board from its box and ESD-protective bag.
  \item \label{enum:step-switch}
  Based on the type of pulses desired on the front panel, set the TTL selection switch
  (SW2.4, see Section~\ref{sec:pulse-ttl-vs-ttlbar}) to the appropriate position:
  \begin{itemize}
    \item TTL pulses -- set the switch to the \textbf{ON} position (default)
    \item TTL-BAR pulses -- set the switch to the \textbf{OFF} position
  \end{itemize}
  \item Set the glitch filter enable switch (SW1.1, see Section~\ref{sec:pulse-jit}) to
  the appropriate position:
  \begin{itemize}
    \item Glitch filter disabled, jitter-free signal at output -- set the switch to the
    \textbf{OFF} position (default)
    \item Glitch filter enabled, introduces output jitter -- set the switch to the
    \textbf{ON} position
  \end{itemize}
  \item Insert the CONV-TTL-BLO board into the VME crate and power on the crate.
  \item Check that the \textit{\textbf{PW}} status LED is lit \textbf{\textit{green}}. If there is
  no RTM in the rear side of the crate, the \textit{\textbf{ERR}} LED will light \textbf{\textit{red}}.
  The \textit{\textbf{TTL}} status LED should also be lit \textit{\textbf{green}} if you set the TTL
  switch to the \textbf{ON} position in step \ref{enum:step-switch}.
  \item Input a TTL (or TTL-BAR) signal into a front panel input channel. When a pulse arrives on the input,
  it is replicated on the output of the same channel. If an RTM board is present in the rear
  part of the VME crate, the pulse will also be replicated on the three blocking outputs of the
  same channel on the rear-panel. The channel pulse LEDs on both the front and rear panels flash
  briefly when a pulse arrives.
  \item Input a blocking signal on a rear panel channel; the pulse LED of the channel will flash
  and the pulse will be replicated on the three blocking outputs of the same channel, as well as
  the TTL channel output on the front panel. If the TTL switch is \textbf{OFF}, the pulse is
  replicated in TTL-BAR.
\end{enumerate}

%======================================================================================
% APP: Typical use cases
%======================================================================================
\section{Typical use cases}
\label{app:use-cases}

%--------------------------------------------------------------------------------------
% SUBSEC: 1 to 12 blocking pulses
%--------------------------------------------------------------------------------------
\subsection{Repeating one blocking pulse to twelve separate ones}

Such a setup is outlined in Figure~\ref{fig:ex-blo-rep}. Only one external blocking signal
is required and it is input to CH1 on the rear panel. A daisy-chain is created
on the front panel starting from CH1 to CH2, up to CH4. The front panel is preferred here
due to smaller delay in replicating pulses (see Section~\ref{sec:pulse-jit}).

Blocking pulses arriving on CH1 then get replicated through the daisy chain from CH1 to CH4.
By connecting all outputs of channels 1 through 4 on the rear panel, the desired pulse
conversion system can be obtained.

Each channel will add a 40~ns delay (390~ns with glitch filter), in addition to the 160~ns (410~ns
with glitch filters) of the CH1 and CH4 blocking conversions.

\begin{figure}[h]
  \centerline{\includegraphics[width=\textwidth]{fig/ex-blo-rep}}
  \caption{Setup for converting one blocking signal into 16 separate ones}
  \label{fig:ex-blo-rep}
\end{figure}

%--------------------------------------------------------------------------------------
% SUBSEC: TTL to TTL-BAR
%--------------------------------------------------------------------------------------
\subsection{Repeating TTL pulses in TTL-BAR}

When the board has already been plugged in and the switch has been set in the
\textbf{OFF} position, only TTL-BAR pulses can be input on a front panel replication channel.
If the user desires to input a TTL pulse and repeat it into TTL-BAR, one of the four
general-purpose inverter channels can be used. Figure~\ref{fig:ex-invert-ttl} shows a
setup for inverting TTL pulses into TTL-BAR on inverting channel A and repeating them
on front panel channel 6.

The inverter channel will add a 30~ns delay to the input TTL signal.

\begin{figure}[h]
  \centerline{\includegraphics[width=\textwidth]{fig/ex-invert-ttl}}
  \caption{Setup for repeating TTL pulses in TTL-BAR}
  \label{fig:ex-invert-ttl}
\end{figure}

%==============================================================================
% APP: Memmap
%==============================================================================
\section{Memory map}
\label{app:memmap}

Note that this appendix contains the memory map for the latest gateware
version. For different gateware versions, the memory map may be different. To get
the memory map for a specific gateware version, see the HDL guide for the corresponding
gateware version at~\cite{ctb-gw-releases}.

Table~\ref{tbl:memmap} shows the complete memory map of the gateware. The
following sections list the memory map of each peripheral.

In order to convert address values to register index values for SNMP access,
the following formula should be used:

\begin{center}
$reg. index = \frac{addr}{4} + 1$
\end{center}

\begin{table}[h]
\caption{CONV-TTL-BLO memory map}
\label{tbl:memmap}
\centerline
{
  \rowcolors{2}{white}{gray!25}
  \begin{tabular}{l l l p{.4\textwidth}}
  \hline
  \multicolumn{1}{c}{\textbf{Peripheral}} & \multicolumn{2}{c}{\textbf{Address range}} & \multicolumn{1}{c}{\textbf{Description}} \\
  \hline
  Board registers & 0x000 & 0x0ff & Converter board registers \\
  MultiBoot       & 0x100 & 0x01f & MultiBoot module \\
  Thermometer     & 0x200 & 0x2ff & Thermometer chip \\
  SDB descriptor  & 0xf00 & 0xfff & SDB descriptor table (see~\cite{sdb}) \\
  \hline
  \end{tabular}
}
\end{table}

%%------------------------------------------------------------------------------
%% SUBSEC: conv_regs
%%------------------------------------------------------------------------------
\include{conv-regs}

%------------------------------------------------------------------------------
% SUBSEC: MultiBoot
%------------------------------------------------------------------------------
\include{multiboot-regs}

%------------------------------------------------------------------------------
% SUBSEC: Thermo
%------------------------------------------------------------------------------
\subsection{Thermometer module}
\label{app:memmap-thermo}

\indent Base address: 0x200

\vspace*{11pt}

\centerline
{
  \rowcolors{2}{white}{gray!25}
  \begin{tabular}{l l l p{.5\textwidth}}
  \hline
  \textbf{Offset} & \textbf{Default} & \textbf{Name} & \textbf{Description} \\
  \hline
  0x00            & 0x00000000       & OWCSR         & One-Wire Control and Status Register \\
  0x04            & 0x00000004       & OWCDR         & One-Wire Clock Divider Registers \\
  \hline
  \end{tabular}
}

\vspace*{11pt}

For details on the bits of the thermometer module access registers, see the
OneWire Master module's documentation~\cite{onewire-core}.

Note that the OWCDR should be set accordingly for proper functioning of the
one-wire timings. The value for the current version of the gateware is
\verb-OWCDR = 0x00130063-.


%------------------------------------------------------------------------------
\end{appendices}
%------------------------------------------------------------------------------

%======================================================================================
% Bibliography
%======================================================================================
\pagebreak
% Make non-cited refs appear in references
\nocite{ohwr}
\nocite{sch}
\bibliographystyle{ieeetr}
\bibliography{ug-conv-ttl-blo}
\addcontentsline{toc}{section}{References}


\end{document}
