source: firmware/FTU/doc/v1/FTU_firmware_v1.tex@ 17479

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