Index: firmware/FTU/doc/v1/FTU_firmware_v1.tex
===================================================================
--- firmware/FTU/doc/v1/FTU_firmware_v1.tex	(revision 10010)
+++ firmware/FTU/doc/v1/FTU_firmware_v1.tex	(revision 10010)
@@ -0,0 +1,555 @@
+\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 v1~~~-~~~September 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 16\,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. Some modules within the FTU design have built-in clock dividers to
+generate custom frequencies which are, however, all derived from the central
+clock.
+
+\subsection{\tt FTU\_dual\_port\_ram}
+\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\_ram} serves as
+an interface to the RAM, the actual gate level description is stored directly
+in the net-list file {\tt FTU\_dual\_port\_ram.ngc}. Thus this file is part of
+the design, although not available as source code. The RAM has a size of
+32\,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 16\,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}.
+
+\section{File Structure}
+
+Table~\ref{tab:files} specifies all source files necessary to compile the
+firmware for the FTU boards\footnote{As of September 2010; the list might be
+  extended, for example, to include source files for the read out of the FPGA
+  serial number (device ID).}. 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\_dual\_port\_ram.vhd} & {\tt FTU/ram} & yes & yes & RAM interface\\
+    \hline
+    {\tt FTU\_dual\_port\_ram.ngc} & {\tt FTU/ram} & 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 & 16~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 31 control and rate registers implemented in the FTU firmware, each
+with a size of 8\,bit. They are organized as a 32-byte RAM (see also
+section~\ref{sec:organization:design:ram}), the last byte of which is empty
+and serves as spare. 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 
+    $0 \dots 7$ & enable patterns & read/write\\
+    \hline 
+    $8 \dots 17$ & rate counters & read-only\\
+    \hline 
+    $18 \dots 27$ & DAC settings & read/write\\
+    \hline
+    $28$ & prescaling $y$ (see section~\ref{sec:organization:design:counter}) & read/write \\
+    \hline
+    $29$ & overflow bits & read-only \\
+    \hline
+    $30$ & check sum error counter & read-only\\
+    \hline
+    $31$ & 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\_B7 & Ct\_B6 & Ct\_B5 & Ct\_B4 & Ct\_B3 & Ct\_B2 & Ct\_B1 & Ct\_B0 \\
+    \hline 
+    11 & Ct\_B15 & Ct\_B14 & Ct\_B13 & Ct\_B12 & Ct\_B11 & Ct\_B10 & Ct\_B9 & Ct\_B8 \\
+    \hline 
+    12 & Ct\_C7 & Ct\_C6 & Ct\_C5 & Ct\_C4 & Ct\_C3 & Ct\_C2 & Ct\_C1 & Ct\_C0 \\
+    \hline 
+    13 & Ct\_C15 & Ct\_C14 & Ct\_C13 & Ct\_C12 & Ct\_C11 & Ct\_C10 & Ct\_C9 & Ct\_C8 \\
+    \hline 
+    14 & Ct\_D7 & Ct\_D6 & Ct\_D5 & Ct\_D4 & Ct\_D3 & Ct\_D2 & Ct\_D1 & Ct\_D0 \\
+    \hline
+    15 & Ct\_D15 & Ct\_D14 & Ct\_D13 & Ct\_D12 & Ct\_D11 & Ct\_D10 & Ct\_D9 & Ct\_D8 \\
+    \hline 
+    16 & Ct\_T7 & Ct\_T6 & Ct\_T5 & Ct\_T4 & Ct\_T3 & Ct\_T2 & Ct\_T1 & Ct\_T0 \\
+    \hline 
+    17 & Ct\_T15 & Ct\_T14 & Ct\_T13 & Ct\_T12 & Ct\_T11 & Ct\_T10 & Ct\_T9 & Ct\_T8 \\
+    \hline
+  \end{tabular}
+  \caption{Mapping of the four patch counters and the trigger counter inside the RAM.}
+  \label{tab:rates}
+\end{table}
+
+\section{DAC Settings}
+
+\begin{table}[htbp]
+  \centering
+  \begin{tabular}{|c|l|}
+    \hline
+    address & data[$7 \dots 0$]\\
+    \hline\hline 
+    18 & DAC\_A\_[$7 \dots 0$] \\
+    \hline 
+    19 & DAC\_A\_[$15 \dots 8$] \\
+    \hline 
+    20 & DAC\_B\_[$7 \dots 0$] \\
+    \hline 
+    21 & DAC\_B\_[$15 \dots 8$] \\
+    \hline 
+    22 & DAC\_C\_[$7 \dots 0$] \\
+    \hline 
+    23 & DAC\_C\_[$15 \dots 8$] \\
+    \hline 
+    24 & DAC\_D\_[$7 \dots 0$] \\
+    \hline 
+    25 & DAC\_D\_[$15 \dots 8$] \\
+    \hline 
+    26 & DAC\_H\_[$7 \dots 0$] \\
+    \hline
+    27 & 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
+    0 & not used & overflow\_T & overflow\_D & overflow\_C & overflow\_B & overflow\_A \\
+    \hline
+  \end{tabular}
+  \caption{Bit mapping inside the RAM overflow register (address 29).}
+  \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 an unique 1-byte address for
+unambiguous identification, which is 0--39 for the FTUs and 192 for the
+FTM. The transmission sequences are of fixed length (16\,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. An 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.
+
+\begin{table}[htbp]
+  \centering
+  \begin{tabular}{|c|l|l|}\hline
+    byte & content & comment \\
+    \hline\hline
+    0 & start delimiter & ASCI @ (binary "01000000")\\
+    \hline
+    1 & destination address & 192 (FTM) or slot position 0--39 (FTUs)\\
+    \hline
+    2 & source address & 192 (FTM) or slot position 0--39 (FTUs)\\
+    \hline
+    3 & instruction / info & see section~\ref{cha:communication:instr}\\
+    \hline
+    4--14 & 11 byte data & DACs, rates, etc.\\
+    \hline
+    15 & 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. For the ping-pong command it is currently
+investigated whether the FTUs can, in addition to just answer, return also the
+FPGA 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).
+
+\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 16-byte data packages is evaluated by means of a Cyclic
+Redundancy Check (CRC). An 8-CCITT CRC has been chosen which is based on the
+polynomial $x^8 + x^2 + x + 1$ (100000111). Bytes 0--14 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 15 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 in its
+corresponding register (RAM address 30). The FTM will consequently run into a
+time-out and repeat its command.
+
+\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 an {\tt INIT} sequence, where default
+values for all registers are written to the RAM. These defaults are all
+defined in the library {\tt ftu\_definitions}. When {\tt INIT} 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 16-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}