source: firmware/FTU/doc/v3/FTU_firmware_v3.tex@ 16378

\documentclass[a4paper,11pt]{report}

\usepackage{float}
\usepackage{graphicx}
\usepackage{url}
\usepackage[T1]{fontenc}
\usepackage{amsmath}
\usepackage{longtable}
\usepackage{parskip}
\usepackage{pifont}
\usepackage{array}

\setlength{\oddsidemargin}{0cm}
\setlength{\evensidemargin}{0cm}
\setlength{\topmargin}{0cm}

\textwidth 6.2in
\textheight 9in
\columnsep 0.25in

\pagestyle{plain}
\setcounter{tocdepth}{1}

\title{\vspace*{-7cm} \Huge \bf FTU Firmware Specifications}
\author{\Large Quirin Weitzel\footnote{Contact for questions and suggestions concerning this
    document: {\tt qweitzel@phys.ethz.ch}}, Patrick Vogler}
\date{\vspace*{0.5cm} \Large v3~~~-~~~November 2010}

\begin{document}

\maketitle

\newpage

\tableofcontents

\chapter{Introduction}

The FACT Trigger Unit (FTU) is a Mezzanine Card attached to the FACT
Pre-Amplifier (FPA) board. On the FPA, the analog signals of nine adjacent
pixels are summed up, and the total signal is compared to a threshold. Four
such trigger patches are hosted by one FPA. The corresponding four digital
trigger signals are processed further by the FTU, generating a single trigger
primitive out of them. A total of 40 FTU boards exists in the FACT
camera. Their trigger primitives are collected at one central point, the FACT
Trigger Master (FTM)\footnote{For more information about the FACT trigger
  system see: P.~Vogler, {\it Development of a trigger system for a Cherenkov
    Telescope Camera based on Geiger-mode avalanche photodiodes}, Master
  Thesis, ETH Zurich, 2010.}. The FTM serves also as slow control master for
the FTUs, which are connected in groups of ten to RS485 data buses for this
purpose. These buses are realized on the midplanes of the four crates inside
the camera.

The main component on each FTU is a FPGA\footnote{Xilinx Spartan-3AN family
  (XC3S400AN-4FGG400C); for programming information see:
  \url{http://www.xilinx.com/support/documentation/user_guides/ug331.pdf}
  (Spartan-3 Generation FPGA User Guide).}, fulfilling different tasks within
the board. The purpose of this document is to describe the main features of
the firmware of this device, which is identical for all 40 boards. After a
brief summary of the FTU functionality and its digital components, a general
overview of the firmware design is given. In the following, all FPGA registers
available for reading and writing are listed. Afterwards the communication
with the FTM is detailed, and the most important finite state machines
implemented are explained.

\chapter{FTU Tasks and Digital Components}

In order to define the thresholds for the individual trigger patches, four
channels of an octal \mbox{12-bit} Digital-to-Analog Converter (DAC) are
used. This chip\footnote{Details concerning specific electronics components as
  well as schematics can be found at the FACT construction page:
  \url{http://ihp-pc1.ethz.ch/FACT} (password protected).} is accessed by the
FPGA through a Serial Peripheral Interface (SPI). A fifth channel of the same
DAC is employed to control a $n$-out-of-4 majority coincidence logic,
generating the trigger primitive out of the patch signals. The FTU can
furthermore switch off single pixels within the trigger patches by disabling
the corresponding input buffers just before the summation stage on the
FPA. However, the decision to switch off a pixel for the trigger or to change
the threshold for a patch is not taken by the FTU itself, but has to come in
form of a command from the FTM.

For each of the four trigger patches, the FTU counts the number of triggers
within a certain time period. Also the number of trigger primitives after the
$n$-out-of-4 majority coincidence is counted. In this way, the rates per patch
and per board are known for each FTU. The counters are implemented inside the
FPGA with a range of 30\,bit. In case the number of triggers exceeds this
limit, an overflow flag is set. The counting period is changeable from outside
between 500\,ms and 128\,s with a resolution of 8\,bit.

Each FTU board has one RS485 communication interface to the FTM. Ten boards
are connected to one bus, where they are operated in slave-mode. Only in case
a read or write command for a specific FTU arrives from the FTM, this board
will react and answer. Broadcast commands are not supported by the current
firmware version. To avoid data collisions on the buses, the FTM has to
address the FTUs one by one to read out the rates for example. A RS485
interface is implemented inside the FPGA, including frame receiving, data
buffering and instruction decoding. It is minimal in the sense that no stacked
commands, command buffering or interrupts are supported. Outside the FPGA, a
RS485 driver/receiver chip translates the signal levels between the
differential bus lines and the FPGA logic levels. This chip is enabled for
data transmission or data receiving, respectively.

\chapter{Firmware Organization}
\label{cha:organization}

The FTU firmware is written in VHDL (VHSIC Hardware Description Language). For
some of its components the Xilinx core generator tools\footnote{Xilinx ISE
  Design Suite, release 11.5, homepage: \url{http://www.xilinx.com}
  (downloads, documentation).} have been used. In this chapter, an overview of
the firmware content is given, followed by a listing of the files containing
the source code. The complete project is available from the FACT
repository\footnote{Project page: \url{https://fact.isdc.unige.ch/trac}
  (password protected).}.

\section{Design Overview}
\label{sec:organization:design}

The highest level entity in the firmware is called {\tt FTU\_top}. Its ports
are the physical connections of the FPGA on the FTU board. Inside {\tt
  FTU\_top} other entities are instantiated, representing different functional
modules. They are discussed in the following subsections. For important
numbers and constants the package {\tt ftu\_constants} inside the library {\tt
  ftu\_definitions} has been created. A second package {\tt ftu\_array\_types}
contains customized array types.

\subsection{\tt FTU\_clk\_gen}

This is an interface to the Digital Clock Managers (DCM) of the FPGA. At the
moment only one DCM is used, providing the central 50\,MHz clock. Once the DCM
has locked and is providing a stable frequency {\tt FTU\_clk\_gen} sends a
ready signal. This is a prerequisite for the board to enter the {\tt RUNNING}
state. {\tt FTU\_clk\_gen} also generates a central 1\,MHz clock for the rate
counters (by division, not using a second DCM). In addition, some modules
within the FTU design have their own built-in clock dividers to generate
custom frequencies.

\subsection{\tt FTU\_dual\_port\_ram64}
\label{sec:organization:design:ram}

All FTU registers which can be set from outside during operation are stored in
a dual-port block RAM (Random Access Memory). The FPGA provides specific
resources for this purpose, and therefore the RAM has been created using the
Xilinx core generator tools. The entity {\tt FTU\_dual\_port\_ram64} serves as
an interface to the RAM, the actual gate level description is stored directly
in the net-list file {\tt FTU\_dual\_port\_ram64.ngc}. Thus this file is part
of the design, although not available as source code. The RAM has a size of
64\,bytes and two fully featured ports to access its content. One port is
based on 1-byte words, the other one on 2-byte words. The corresponding
address space is presented together with the register tables in
chapter~\ref{cha:registers}. In addition to the control registers, also the
current counter readings are stored in the RAM.

\subsection{\tt FTU\_rate\_counter}
\label{sec:organization:design:counter}

Here the trigger counting is done. A rate counter has a range of 30\,bit and
counts until a defined period is finished. This period is derived from an
8-bit prescaling value $y$ as $ T = \frac{y+1}{2}$\,s. In total five such
counters are instantiated which are running and set up synchronously. If the
FTU settings are changed during operation all counters are reset. Only in case
a full period has been finished without interruption, the number of counts
from each counter is stored in the RAM. An overflow flag is set by the
counters if necessary.

\subsection{\tt FTU\_spi\_interface}

The octal DAC defining the trigger thresholds is controlled by means of a
SPI. As soon as the {\tt FTU\_spi\_interface} entity receives a start signal,
it will clock out the data pending at one of its input ports to the DAC. These
data are provided in form of a customized array. The generation of the serial
clock, the distribution of the DAC values to the right addresses and the
actual transmission of the data to the chip are performed by three more
entities, which are instantiated inside {\tt FTU\_spi\_interface}. Once the
transmission has started or finished, respectively, a signal is pulled.

\subsection{\tt FTU\_rs485\_control}

The communication between the FTU and the FTM is handled by a RS485
interface. The top level entity of this module is called {\tt
  FTU\_rs485\_control}. It contains a state machine and further sub-entities
for frame receiving or transmitting, byte buffering and instruction
decoding. The details of the underlying protocol and the possible instructions
are detailed in chapter~\ref{cha:communication}. In case an instruction has
been decoded successfully, the main FTU control is informed and the
corresponding data (like new DAC values) are provided. After the command has
been executed an answer is send to the FTM. {\tt FTU\_rs485\_control} has
direct control of the involved transmitter/receiver chip outside the FPGA and
takes care that it is only transmitting if this particular FTU has been
contacted by the FTM. In this way also the rates are send on request. The baud
rate is adjustable and defined in the library {\tt ftu\_definitions}.

\subsection{\tt FTU\_control}

This entity contains the main state machine of the FTU firmware. It receives
control, ready, start, etc. flags from all modules and interfaces and reacts
accordingly by changing to a new state. This may be done with some delay,
depending on what the board is doing at the moment. {\tt FTU\_control} is
furthermore the only place in the design from where the RAM is read or
written. The state machine is described in more detail in
chapter~\ref{cha:fsm}.

\subsection{\tt FTU\_dna\_gen}
\label{sec:organization:design:dna}

In order to be able to unambiguously identify each FTU during operation, the
device identifier\footnote{This unique identifier has 57\,bit and is built-in
  for each FPGA of the Spartan-3A series. For more information see:
  \url{http://www.xilinx.com/support/documentation/user_guides/ug332.pdf}
  (Spartan-3 Generation Configuration User Guide).} (DNA) of its FPGA is
used. After power-up this DNA is read-out once by {\tt FTU\_dna\_gen} and
stored for later usage inside {\tt FTU\_top} as a permanent signal.

\section{File Structure}

Table~\ref{tab:files} specifies all source files necessary to compile the
firmware for the FTU boards\footnote{As of November 2010; the file structure
  might still be changed.}. For each file its location path inside the
directory {\tt firmware} of the FACT repository is stated. Furthermore it is
indicated whether a certain file is needed for the simulation and/or the
hardware implementation. The design entities described in
section~\ref{sec:organization:design} are contained in those files which have
the corresponding prefix. The file {\tt ucrc\_par.vhd} has been downloaded
from OpenCores\footnote{Ultimate CRC project:
  \url{http://www.opencores.org/cores/ultimate_crc} (free software under the
  terms of the GNU General Public License).}.

\begin{table}[htbp]
  \centering
  \begin{tabular}{|l|l|l|l|l|}
    \hline
    file name & location & simulation & implement & comment \\
    \hline\hline
    {\tt FTU\_top.vhd} & {\tt FTU} & yes & yes & top level entity\\
    \hline
    {\tt FTU\_top\_tb.vhd} & {\tt FTU} & yes & no & test bench\\
    \hline
    {\tt ftu\_definitions.vhd} & {\tt FTU} & yes & yes & library\\
    \hline
    {\tt ftu\_board.ucf} & {\tt FTU} & no & yes & pin constraints\\
    \hline
    {\tt FTU\_control.vhd} & {\tt FTU} & yes & yes & top state machine\\
    \hline\hline
    {\tt FTU\_clk\_gen.vhd} & {\tt FTU/clock} & yes & yes & clock interface\\
    \hline
    {\tt FTU\_dcm\_50M\_to\_50M.vhd} & {\tt FTU/clock} & yes & yes & clock manager\\
    \hline\hline
    {\tt FTU\_rate\_counter.vhd} & {\tt FTU/counter} & yes & yes & trigger counter\\
    \hline\hline
    {\tt FTU\_spi\_interface.vhd} & {\tt FTU/dac\_spi} & yes & yes & SPI top entity\\
    \hline
    {\tt FTU\_spi\_clock\_gen.vhd} & {\tt FTU/dac\_spi} & yes & yes & serial clock\\
    \hline
    {\tt FTU\_distributor.vhd} & {\tt FTU/dac\_spi} & yes & yes & DAC loop\\
    \hline
    {\tt FTU\_controller.vhd} & {\tt FTU/dac\_spi} & yes & yes & low level SPI\\
    \hline\hline
    {\tt FTU\_dna\_gen.vhd} & {\tt FTU/dna} & yes & yes & DNA readout\\
    \hline\hline
    {\tt FTU\_dual\_port\_ram64.vhd} & {\tt FTU/ram64} & yes & yes & RAM interface\\
    \hline
    {\tt FTU\_dual\_port\_ram64.ngc} & {\tt FTU/ram64} & no & yes & RAM netlist\\
    \hline\hline
    {\tt FTU\_rs485\_control.vhd} & {\tt FTU/rs485} & yes & yes & RS485 top entity\\
    \hline
    {\tt FTU\_rs485\_interpreter.vhd} & {\tt FTU/rs485} & yes & yes & data decoding\\
    \hline
    {\tt FTU\_rs485\_receiver.vhd} & {\tt FTU/rs485} & yes & yes & 28-byte buffer\\
    \hline
    {\tt FTU\_rs485\_interface.vhd} & {\tt FTU/rs485} & yes & yes & low level RS485\\
    \hline
    {\tt ucrc\_par.vhd} & {\tt FTU/rs485} & yes & yes & check sum\\
    \hline
  \end{tabular}
  \caption{List of all source files needed to compile the FTU firmware.}
  \label{tab:files}
\end{table}

\chapter{Register Tables}
\label{cha:registers}

There are 40 accessible control and rate registers implemented in the FTU
firmware, each with a size of 8\,bit. They are organized as a 64-byte RAM (see
also section~\ref{sec:organization:design:ram}), the last 24 bytes of which
are empty and serve as spares. Table~\ref{tab:RAM} presents an overview of the
address space inside the RAM, more details can be found in
tables~\ref{tab:enables} - \ref{tab:overflow}. Registers marked as read-only
cannot be written by the FTM, but are updated by the FTU itself.

\begin{table}[htbp]
  \centering
  \begin{tabular}{|c|l|l|}
    \hline
    RAM address & register block & comment\\
    \hline\hline 
    $00 \dots 07$ & enable patterns & read/write\\
    \hline 
    $08 \dots 27$ & rate counters & read-only\\
    \hline 
    $28 \dots 37$ & DAC settings & read/write\\
    \hline
    $38$ & prescaling $y$ (see section~\ref{sec:organization:design:counter}) & read/write \\
    \hline
    $39$ & overflow bits & read-only \\
    \hline
    $40 \dots 63$ & empty & spare \\
    \hline
  \end{tabular}
  \caption{Overview of the register mapping inside the RAM.}
  \label{tab:RAM}
\end{table}

\section{Enable Patterns}

\begin{table}[htbp]
  \centering
  %\small
  \begin{tabular}{|c||l|l|l|l|l|l|l|l|}
    \hline
    address & bit~7 & bit~6 & bit~5 & bit~4 & bit~3 & bit~2 & bit~1 & bit~0 \\
    \hline\hline
    00 & En\_A7 & En\_A6 & En\_A5 & En\_A4 & En\_A3 & En\_A2 & En\_A1 &
    En\_A0 \\
    \hline 
    01 & \- & \- & \- & \- & \- & \- & \- & En\_A8 \\
    \hline 
    02 & En\_B7 & En\_B6 & En\_B5 & En\_B4 & En\_B3 & En\_B2 & En\_B1 &
    En\_B0 \\
    \hline
    03 & \- & \- & \- & \- & \- & \- & \- & En\_B8 \\
    \hline 
    04 & En\_C7 & En\_C6 & En\_C5 & En\_C4 & En\_C3 & En\_C2 & En\_C1 &
    En\_C0 \\
    \hline 
    05 & \- & \- & \- & \- & \- & \- & \- & En\_C8 \\
    \hline 
    06 & En\_D7 & En\_D6 & En\_D5 & En\_D4 & En\_D3 & En\_D2 & En\_D1 &
    En\_D0 \\
    \hline 
    07 & \- & \- & \- & \- & \- & \- & \- & En\_D8\\
    \hline 
  \end{tabular}
  \caption{Mapping of the $4 \times 9$ enable bits inside the RAM.}
  \label{tab:enables}
\end{table}

\section{Rate Counters}

\begin{table}[htbp]
  \centering
  %\small
  \begin{tabular}{|c||l|l|l|l|l|l|l|l|}
    \hline
    address & bit~7 & bit~6 & bit~5 & bit~4 & bit~3 & bit~2 & bit~1 & bit~0 \\
    \hline\hline 
    08 & Ct\_A7 & Ct\_A6 & Ct\_A5 & Ct\_A4 & Ct\_A3 & Ct\_A2 & Ct\_A1 & Ct\_A0 \\
    \hline 
    09 & Ct\_A15 & Ct\_A14 & Ct\_A13 & Ct\_A12 & Ct\_A11 & Ct\_A10 & Ct\_A9 & Ct\_A8 \\
    \hline
    10 & Ct\_A23 & Ct\_A22 & Ct\_A21 & Ct\_A20 & Ct\_A19 & Ct\_A18 & Ct\_A17 & Ct\_A16 \\
    \hline 
    11 & 0 & 0 & Ct\_A29 & Ct\_A28 & Ct\_A27 & Ct\_A26 & Ct\_A25 & Ct\_A24 \\
    \hline\hline
    $\dots$ & $\dots$ & $\dots$ & $\dots$ & $\dots$ & $\dots$ & $\dots$ & $\dots$ & $\dots$ \\
    \hline\hline
    20 & Ct\_D7 & Ct\_D6 & Ct\_D5 & Ct\_D4 & Ct\_D3 & Ct\_D2 & Ct\_D1 & Ct\_D0 \\
    \hline
    21 & Ct\_D15 & Ct\_D14 & Ct\_D13 & Ct\_D12 & Ct\_D11 & Ct\_D10 & Ct\_D9 & Ct\_D8 \\
    \hline
    22 & Ct\_D23 & Ct\_D22 & Ct\_D21 & Ct\_D20 & Ct\_D19 & Ct\_D18 & Ct\_D17 & Ct\_D16 \\
    \hline 
    23 & 0 & 0 & Ct\_D29 & Ct\_D28 & Ct\_D27 & Ct\_D26 & Ct\_D25 & Ct\_D24 \\
    \hline\hline
    24 & Ct\_T7 & Ct\_T6 & Ct\_T5 & Ct\_T4 & Ct\_T3 & Ct\_T2 & Ct\_T1 & Ct\_T0 \\
    \hline 
    25 & Ct\_T15 & Ct\_T14 & Ct\_T13 & Ct\_T12 & Ct\_T11 & Ct\_T10 & Ct\_T9 & Ct\_T8 \\
    \hline
    26 & Ct\_T23 & Ct\_T22 & Ct\_T21 & Ct\_T20 & Ct\_T19 & Ct\_T18 & Ct\_T17 & Ct\_T16 \\
    \hline 
    27 & 0 & 0 & Ct\_T29 & Ct\_T28 & Ct\_T27 & Ct\_T26 & Ct\_T25 & Ct\_T24 \\
    \hline
  \end{tabular}
  \caption{Mapping of the four patch counter (A--D) and the trigger counter
    reading (T) inside the RAM. The two most significant bits of the 32 bits per counter are always
    set to 0.}
  \label{tab:rates}
\end{table}

\section{DAC Settings}

\begin{table}[htbp]
  \centering
  \begin{tabular}{|c|l|}
    \hline
    address & data[$7 \dots 0$]\\
    \hline\hline 
    28 & DAC\_A\_[$7 \dots 0$] \\
    \hline 
    29 & DAC\_A\_[$15 \dots 8$] \\
    \hline 
    $\dots$ & $\dots$\\
    \hline 
    34 & DAC\_D\_[$7 \dots 0$] \\
    \hline 
    35 & DAC\_D\_[$15 \dots 8$] \\
    \hline 
    36 & DAC\_H\_[$7 \dots 0$] \\
    \hline
    37 & DAC\_H\_[$15 \dots 8$] \\
    \hline
  \end{tabular}
  \caption{Mapping of the DAC values (12\,bit) for the thresholds (DAC\_A -- DAC\_D) and the
    $n$-out-of-4 logic (DAC\_H) inside the RAM; the bits $15\dots 12$ are filled up with zeros.}
  \label{tab:dacs}
\end{table}

\section{Overflow Bits}

\begin{table}[htbp]
  \centering
  \begin{tabular}{|l|c|c|c|c|c|c|}
    \hline
    bit & $7 \dots 5$ & 4 & 3 & 2 & 1 & 0 \\
    \hline\hline
    content & not used & overflow\_T & overflow\_D & overflow\_C & overflow\_B & overflow\_A \\
    \hline
  \end{tabular}
  \caption{Bit mapping inside the RAM overflow register (address 39).}
  \label{tab:overflow}
\end{table}

\chapter{Communication with FTM}
\label{cha:communication}

The slow control system between the FTU boards (slaves) and the FTM (master)
is based on two transmission sequences: Either the FTM is sending data to a
particular FTU, or a particular FTU is answering to the FTM. Broadcast
commands are not supported. Each board has a unique 1-byte address for
identification on the RS485 buses, which is 0--63 for the FTUs\footnote{Two
  bits are used to specify the crate, four bits to indicate the slot position
  within a crate. This 6-bit address is different from the 57-bit DNA which is
  FPGA-bound (see section~\ref{sec:organization:design:dna}).} and 192 for the
FTM. The transmission sequences are of fixed length (28\,byte) and, if
necessary, filled up with arbitrary data. In case the data transmission is
disturbed or not complete, a time-out system ensures that the communication
doesn't get stuck\footnote{At a baud rate of 250\,kHz, for example, this
  time-out is set to 2\,ms on the FTU side.}. In the following, the slow
control protocol, the instruction codes and the check sum error-detection are
discussed.

\section{Transmission Protocol}

Table~\ref{tab:protocol} summarizes the structure of the data sequences sent
between the FTM and the FTUs. A FTU only replies if contacted by the FTM. The
answer is a copy of the received data package with swapped source/destination
address and eventually the requested data. Byte 26 is used to transmit the
number of CRC errors counted by a FTU until a valid sequence arrived. In that
case the number of errors is communicated and the error counter is set to 0.

\begin{table}[htbp]
  \centering
  \begin{tabular}{|c|l|l|}\hline
    byte & content & comment \\
    \hline\hline
    $00$ & start delimiter & ASCI @ (binary "01000000")\\
    \hline
    $01$ & destination address & 192 (FTM) or slot position 0--63 (FTUs)\\
    \hline
    $02$ & source address & 192 (FTM) or slot position 0--63 (FTUs)\\
    \hline
    $03$ & firmware ID &  firmware version of source FPGA\\
    \hline
    $04$ & instruction / info & see section~\ref{cha:communication:instr}\\
    \hline
    $05 \dots 25$ & 21 byte data & DACs, rates, etc.\\
    \hline
    $26$ & CRC error counter & number of CRC errors on FTU \\
    \hline
    $27$ & check sum & CRC-8-CCITT, see section~\ref{cha:communication:crc}\\
    \hline
  \end{tabular}
  \caption{Composition of the FTM-FTU slow control data packages.}
  \label{tab:protocol}
\end{table}

\section{Instruction Table}
\label{cha:communication:instr}

A set of eight instructions has been foreseen for the communication between
the FTM and the FTUs. They are listed in table~\ref{tab:instructions}
including a short description. In case a FTU receives the ping-pong command,
it returns also the DNA of its FPGA (see
section~\ref{sec:organization:design:dna}). Combined with the 6-bit address,
which is related to the geographical position insided the camera crates, it is
therefore possible to identify each FTU.

\begin{table}[htbp]
  \centering
  \begin{tabular}{|c|l|l|}
    \hline
    code & instruction & description \\
    \hline\hline 
    00 & set DAC & write new values into DAC registers \\
    \hline
    01 & read DAC & read back content of DAC registers \\
    \hline
    02 & read rates & read out rates and overflow bits \\
    \hline
    03 & set enable & write new patterns into enable registers \\
    \hline
    04 & read enable & read back content of enable registers \\
    \hline
    05 & ping-pong & ping a FTU to check communication (see text)\\
    \hline
    06 & set counter mode & write into the prescaling register \\
    \hline
    07 & read counter mode & read back prescaling and overflow registers \\
    \hline
  \end{tabular}
  \caption{Instruction set for the FTM-FTU slow control communication.}
  \label{tab:instructions}
\end{table}

\section{CRC Calculation}
\label{cha:communication:crc}

The integrity of the 28-byte data packages is evaluated by means of a Cyclic
Redundancy Check (CRC). The 8-CCITT CRC has been chosen which is based on the
polynomial $x^8 + x^2 + x + 1$ (00000111, omitting the most significant
bit). Bytes 0--26 of table~\ref{tab:protocol} constitute the input vector for
the CRC calculation, the resulting 1-byte check sum being compared with the
one transmitted by the FTM (byte 27 in table~\ref{tab:protocol}). If the check
sum turns out to be wrong, the FTU doesn't answer and increases the number of
error counts. The FTM will consequently run into a time-out and repeat its
command. After a valid sequence has finally arrived, the FTU will include in
its answer the number of CRC errors counted (byte 26 in
table~\ref{tab:protocol}) and reset the error counter.

\chapter{Finite State Machines}
\label{cha:fsm}

There are several finite state machines (FSM) used in the FTU firmware design,
distributed over several files. They are in principal all running in parallel,
some of them are, however, only waking up if triggered by the main
control. This is for example the case for the SPI interface controlling the
DAC settings. Since the most complicated FSMs are inside {\tt FTU\_control}
and {\tt FTU\_rs485\_control} (see section~\ref{sec:organization:design}),
they are explained in more detail in this chapter.

\section{Main Control FSM}

This state machine has full control over the FTU board during operation. After
power-up or reboot it is in an {\tt IDLE} state, waiting for the DCMs to
lock. Afterwards it passes through two {\tt INIT} sequences, where default
values for all registers are written to the RAM and the DNA is read out. The
defaults are all defined in the library {\tt ftu\_definitions}. When the
initialization has finished, the {\tt RUNNING} state is entered. This is the
principal state during which the board is counting triggers. {\tt RUNNING} is
left only if a counting period has finished and the number of counts is stored
in the RAM, or if a command has arrived via RS485 and is communicated by the
responsible FSM (see next section). A dedicated state has been implemented for
each possible command and, if appropriate, also for the subsequent change of
settings (e.g. {\tt CONFIG\_DAC}). In any case the board goes back to {\tt
  RUNNING}.

\section{RS485 Control FSM}

The main and default state of this FSM is {\tt RECEIVE}. This means that the
RS485 receiver is enabled and the board is waiting for commands from the
FTM. If a full 28-byte package has arrived and correctly been
decoded\footnote{This involves a further state machine which is inside the
  file {\tt FTU\_rs485\_interpreter.vhd}}, the main control FSM is informed
about the instruction (e.g. new DACs). The RS485 FSM then enters a wait state
(e.g. {\tt SET\_DAC\_WAIT}) until it gets an internal ready signal. It
subsequently sends the answer to the FTM (e.g. {\tt SET\_DAC\_TRANSMIT}) and
goes back to {\tt RECEIVE}. While during {\tt RECEIVE} the RS485 FSM and all
processes below are running in parallel to the main control FSM, the sequence
of states in case a command has arrived is prescribed.

\end{document}