%==============================================================================
% 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
\addcontentsline{toc}{section}{Revision history}
\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
  08-08-2014 & 0.1 & First draft, gateware release v0.0 \\
  12-08-2014 & 1.0 & First release, after 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} \\
  \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 \\
  FM     & Front Module (VME board) \\
  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 (VME board) \\
  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-RS485 is an open hardware design \cite{ohwr} intended for replicating TTL and RS-485
pulses, or for timing distribution. The main features of the board are:

\begin{itemize}
  \item VME64x form-factor
  \item Possibility to use as timing repeater card
  \item Six independent pulse replication channels, each channel capable of replicating
  \begin{itemize}
    \item TTL to TTL
    \item TTL to RS-485
    \item TTL-BAR to TTL-BAR
    \item TTL-BAR to RS-485
    \item RS-485 to TTL
    \item RS-485 to TTL-BAR
    \item RS-485 to RS-485
  \end{itemize}
  \item Four general-purpose inverter channels
  \begin{itemize}
    \item TTL to TTL-BAR
    \item TTL-BAR to TTL
  \end{itemize}
  \item Each TTL and inverter channel has 50~$\Omega$ input termination
  \item Each TTL and inverter channel capable of driving 50~$\Omega$ load
  \item Each RS-485 channel capable of driving up to 256 nodes
  \item Each RS-485 channel contains lack of signal detection logic
  \item SFP connector
  \item Diagnostics
  \begin{itemize}
    \item converter board ID
    \item gateware version
    \item state of on-board switches and RTM detection lines
    \item line state at board input
    \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}

Pulse conversion is obtained by combining the CONV-TTL-RS485 front module (FM) board
with a CONV-TTL-RTM rear-transition module (RTM) together with an attached
CONV-TTL-RTM-RS485 piggyback board, as shown in Figure~\ref{fig:conv-sys-bd}.
In this case, a pulse on a channel's input on any side (TTL on the FM side or RS-485 on the
RTM side) is replicated on both the FM and the RTM outputs for the channel.

This document presents various details about the CONV-TTL-RS485 board. It is based
on gateware release v0.0 (see the gateware releases page~\cite{conv-ttl-rs485-gw-releases}).

\begin{figure}[h]
  \centerline{\includegraphics[width=\textwidth]{fig/conv-sys-bd}}
  \caption{\label{fig:conv-sys-bd} Converter system block diagram}
\end{figure}


%------------------------------------------------------------------------------
\subsection{Additional documentation}
%------------------------------------------------------------------------------

\begin{itemize}
  \item CONV-TTL-RS485 OHWR Wiki page~\cite{conv-ttl-rs485-ohwr}
  \item CONV-TTL-RS485 schematics~\cite{conv-ttl-rs485-sch}
  \item CONV-TTL-RS485 HDL Guide~\cite{conv-ttl-rs485-hdlg}
\end{itemize}

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

Two panels exist in the context of the RS-485 pulse repeater boards. The first of these is the
\textit{front panel}, which corresponds to FM 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 the RTM boards. The rear panel offers RS-485 LEMO0 connectors and status
LEDs for pulse replication confirmation.

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

The front panel corresponding to CONV-TTL-RS485 FM boards is shown in Figure~\ref{fig:fp}.
It consists of several ports and status LEDs, which are detailed in the following
subsections.

\begin{figure}
    \centerline{\includegraphics[scale=.75]{fig/front-panel}}
    \caption{Front panel}
    \label{fig:fp}
\end{figure}

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

\begin{table}[h]
\caption{System status LEDs on the CONV-TTL-RS485 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-RS485 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 \\
  \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 \\
  \textit{MULTICAST} & Multicast switch status LEDs \newline
                 -- \textbf{Green} when the corresponding multicast switch is ON \newline
                 -- \textbf{Off} otherwise \\
  \hline
  \end{tabular}
}
\end{table}

%--------------------------------------------------------------------------------------
\subsubsection{TTL inputs and outputs}
Six of the LEMO 00 connectors on the FM 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 RS-485 outputs of the same channel on the rear panel, if an RTM
board with an attached RS-485 piggyback is present. Similarly, if an RS-485 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[width=.8\textwidth]{fig/ttl-chan}}
  \caption{Pulse repetition on front panel}
  \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 RS-485 outputs
on the RTM. The input signal is simply passed through an inverter and the FPGA, and presented at the
channel output.

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

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

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

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

Each RS-485 output on a channel has its dedicated transceiver capable of driving 256 nodes.

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{Rear panel}
  \label{fig:rear-panel}
\end{figure}

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

There are twelve switches provided on-board the CONV-TTL-RS485. Eight of these switches
are general-purpose, and four of them are dedicated multicast switches, for selecting the
board's multicast address.

Figure~\ref{fig:switches} shows the switches. Table~\ref{tbl:switches} lists the used
general-purpose switches.

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.

\begin{figure}[h]
  \centerline{\includegraphics[width=.55\textwidth]{fig/switches}}
  \caption{Switches on the CONV-TTL-RS485 board}
  \label{fig:switches}
\end{figure}

\begin{table}[htbp]
  \caption{General-purpose switches on CONV-TTL-RS485}
  \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-rep}) \newline
            \textbf{ON} -- glitch filter enabled, output jitter present \newline
            \textbf{OFF} -- glitch filter disabled, no output jitter \textbf{(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 \textbf{(default)} \newline
            \textbf{OFF} -- TTL channels receive and generate TTL-BAR \\
    \hline
    \end{tabular}
  }
\end{table}

The multicast switches shown in Figure~\ref{fig:switches} can be used to select a
multicast address for the board. At the moment, no particular functionality is defined
in this respect, but setting a switch to ON also lights the corresponding front-panel
multicast bicolor LED.

The status of all on-board switches can be read from status registers; for more information
see Section~\ref{sec:diag-sw-rtmdet}.

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

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

There are three pulse types that can be generated by the CONV-TTL-RS485 card:
\begin{itemize}
  \item TTL/TTL-BAR -- 3~V across 50~$\Omega$ load (see also Section~\ref{sec:pulse-ttl-vs-ttlbar})
  \item RS-485 -- approx. 8.6~V differential with no load; exact amplitude under load has
  not been measured
\end{itemize}

No pulse width, nor maximum frequency is defined for the pulse, the card simply passes
through the pulses it receives at the input (see Section~\ref{sec:pulse-rep}).

%--------------------------------------------------------------------------------------
% 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}). 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.

\begin{figure}[hbtp]
  \centerline{\includegraphics[width=.6\textwidth]{fig/ttl-vs-ttlbar}}
  \caption{TTL and TTL-BAR signals}
  \label{fig:pulse-ttl-vs-ttlbar}
\end{figure}

\begin{figure}[hbtp]
  \centerline{\includegraphics[width=.9\textwidth]{fig/switches-ttl}}
  \caption{TTL/TTL-BAR selection switch}
  \label{fig:switches-ttl}
\end{figure}

%--------------------------------------------------------------------------------------
% SUBSEC: Rep details
%--------------------------------------------------------------------------------------
\pagebreak
\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. Each channel has a dedicated logic block as that in Figure~\ref{fig:pulse-rep}.

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

Signals from either TTL or RS-485 side are passed directly to the channel's TTL and RS-485 outputs.
The \textit{ttlsel} signal in Figure~\ref{fig:pulse-rep} is the signal coming from the TTL switch
and it is used to select between whether the signals at the inputs and outputs should be inverted in
order to generate TTL-BAR pulses.

For TTL-BAR and RS-485 pulses, signal loss detection logic is needed, since the idle state with no signal
in such cases is logic high, which would lead to a masking of the other input at the OR gate and subsequently
a pulse. On the TTL-BAR side, this is done inside the \textit{no signal detect} block by means of checking
whether the line is high for 100~${\mu}s$ and disabling the TTL line if it is. The \textit{no signal detect}
block resets when a signal is detected at the input, thus enabling the line.

On the RS-485 side, it is implemented by means of a NAND gate which implements the signal loss detection
mechanism described in ~\cite{rs485-fs}. Together with the data line and no signal detection transceivers
on board the CONV-TTL-RS485, the NAND gate disables the line when both transceivers are in failsafe mode.

At reset or board power-up, during the time that the \textit{no signal detect} block is waiting
the 100~${\mu}s$ until disabling the line with no signal on it, a pulse will be generated
due to the high state of the line. For this reason, the \textit{first pulse inhibit} block has
been implemented, which keeps the line disabled for an extra 100~${\mu}s$ after reset. Note
that the block is only active for 100~${\mu}s$ after reset, no pulses will be rejected in the
occasion of the cable being removed. \textbf{It is for this reason that a pulse will be generated
whenever the cable is removed when the board is in TTL-BAR repetition mode.}

A glitch filter may be optionally selected by means of the glitch filter switch. The glitch
filter is enabled by the \textit{glitch filter} general-purpose switch~\ref{fig:switches-gf}.
The glitch filter ignores signals with a width shorter than 50~ns, but also introduces
a 50~ns jitter on the leading edge, due to the fact it is sampling the line with a 20~MHz clock.

\begin{figure}[htbp]
  \centerline{\includegraphics[width=.9\textwidth]{fig/switches-gf}}
  \caption{Glitch filter enable switch}
  \label{fig:switches-gf}
\end{figure}

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

It is possible to communicate to the CONV-TTL-RS485 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-RS485 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-RS485 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-RS485 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-RS485 FPGA}
  \label{fig:comm}
\end{figure}

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

The first method to access registers on the CONV-TTL-RS485 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-RS485 ID of a CONV-TTL-RS485 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{T485}.

\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: 54343835
%>
\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{T485}, 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-RS485, 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-RS485 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-RS485 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: "54343538"
\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-RS485, 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 (SR -- see Appendix~\ref{app:conv-regs-sr}) 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-RS485. Diagnostics data about a CONV-TTL-RS485
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-RS485:

\begin{itemize}
  \item converter board identification
  \item reading of the FPGA gateware version
  \item reading the state of the lines at board input
  \item reading the state of the on-board switches
  \item reading the state of the RTM detection lines
  \item remotely reset the FPGA logic
\end{itemize}

%------------------------------------------------------------------------------
% 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-RS485, the BIDR contains the ASCII string \textbf{T485},
for TTL-to-RS485 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: Line state
%------------------------------------------------------------------------------
\subsection{Line state}
\label{sec:diag-line-state}

The line state can be read from the Line Status Register (LSR -- see Appendix~\ref{app:conv-regs-lsr}).
Each bit corresponding to an input line state reflects the state at the board
input, prior to inputting the signal to the Schmitt trigger.
In addition, the state of the no signal detect logic for RS-485 circuitry is
also reflected in the LSR.

\begin{figure}
  \centerline{\includegraphics[width=.8\textwidth]{fig/line-stat}}
  \caption{\label{fig:line-stat} Line state mapping in the LSR}
\end{figure}

%------------------------------------------------------------------------------
% 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}).
An active-high logic has been selected for both the switches and the RTM
detection lines~\cite{rtm-det}, therefore if a switch is on, or an RTM line is active,
its corresponding bit in the SR is set high.

\begin{figure}[h]
  \centerline{\includegraphics[width=.7\textwidth]{fig/rtm-det}}
  \caption{\label{fig:rtm-det} RTM detection lines to status register}
%\end{figure}
%
%\begin{figure}[h]
  \centerline{\includegraphics[width=.7\textwidth]{fig/sr-switches}}
  \caption{\label{fig:sr-switches} Switch mapping to the SR}
\end{figure}

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

The user can remotely reset the FPGA logic inside the CONV-TTL-RS485 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-RS485 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: System Errors
%------------------------------------------------------------------------------
\subsection{System errors}
\label{sec:diag-syserr}

%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 to see exactly what caused the system error.
%
%The system errors defined for the CONV-TTL-RS485, together with the relevant bits
%set when the error occurs, are shown in Table~\ref{tbl:syserr}.

\begin{table}[h]
  \caption{System errors on the CONV-TTL-RS485}
  \label{tbl:syserr}
  \centerline
  {
    \rowcolors{2}{white}{gray!25}
    \begin{tabular}{l l p{.5\textwidth}}
    \hline
    \multicolumn{1}{c}{\textbf{Error}} & \multicolumn{1}{c}{\textbf{Register}} &
    \multicolumn{1}{c}{\textbf{Description}} \\
    \hline
    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 \\
    \hline
    \end{tabular}  
  }
\end{table}

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

CONV-TTL-RS485 boards 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-RS485. 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-RS485.

%%--------------------------------------------------------------------------------------
%% 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-RS485}
\label{sec:reprog-bitstreams}

The FPGA on-board the CONV-TTL-RS485 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-RS485 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-RS485 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: Don't program bitstreams w/o the ICAP
%--------------------------------------------------------------------------------------
\subsection{Flash memory map}
\label{sec:reprog-flash-memmap}

The memory map for the CONV-TTL-RS485 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: 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.

%%--------------------------------------------------------------------------------------
%% SUBSEC: Status on reception
%%--------------------------------------------------------------------------------------
%\subsection{Gateware status on reception}
%\label{sec:reprog-fwstat}
%
%CONV-TTL-RS485 boards arrive with the Header and Golden bitstreams, along with bitstream
%version 1.0 (see the bitstream releases webpage~\cite{conv-ttl-rs485-releases} for more details)
%programmed into the flash.

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

\begin{appendices}

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

%--------------------------------------------------------------------------------------
% SUBSEC: Timing distrib.
%--------------------------------------------------------------------------------------
\subsection{Timing distribution}

Due to the channel pass-through architecture of the pulse repetition logic, the
CONV-TTL-RS485 can be used as a timing distribution system, to distribute up to 18
timing signals out of one CONV-TTL-RS485 system. Figure~\ref{fig:ex-timing}
shows an example setup for this.

\begin{figure}[h]
  \centerline{\includegraphics[width=\textwidth]{fig/ex-timing}}
  \caption{\label{fig:ex-timing} Setup for timing distribution}
\end{figure}

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

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

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.

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

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{\textit{conv\_common\_gw} 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 & Coverter board registers \\
  MultiBoot       & 0x100 & 0x110 & MultiBoot module \\
  SDB descriptor  & 0xf00 & 0xfff & SDB descriptor (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: 0x080
%
%\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
\bibliographystyle{ieeetr}
\bibliography{ug-conv-ttl-rs485}
\addcontentsline{toc}{section}{References}

\end{document}
