Index: firmware/FTU/doc/v2/FTU_firmware_v2.tex =================================================================== --- firmware/FTU/doc/v2/FTU_firmware_v2.tex (revision 10047) +++ firmware/FTU/doc/v2/FTU_firmware_v2.tex (revision 10047) @@ -0,0 +1,579 @@ +\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 v2~~~-~~~October 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 October 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 41 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 23 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$ & check sum error counter & read-only\\ + \hline + $41 \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 + 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 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). An 8-CCITT CRC has been chosen which is based on the +polynomial $x^8 + x^2 + x + 1$ (100000111). 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 in its +corresponding register (RAM address 40). 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 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} Index: firmware/FTU/ftu_definitions.vhd =================================================================== --- firmware/FTU/ftu_definitions.vhd (revision 10037) +++ firmware/FTU/ftu_definitions.vhd (revision 10047) @@ -78,4 +78,5 @@ --communication with FTM constant RS485_BAUD_RATE : integer := 250000; -- bits / sec in our case + constant RS485_TIMEOUT : integer := (INT_CLK_FREQUENCY * 2) / 1000; -- 2ms @ 50MHz (100000 clk periods) constant RS485_BLOCK_WIDTH : integer := 224; -- 28 byte protocol constant RS485_START_DELIM : std_logic_vector(7 downto 0) := "01000000"; -- start delimiter Index: firmware/FTU/rs485/FTU_rs485_interpreter.vhd =================================================================== --- firmware/FTU/rs485/FTU_rs485_interpreter.vhd (revision 10037) +++ firmware/FTU/rs485/FTU_rs485_interpreter.vhd (revision 10047) @@ -92,6 +92,6 @@ int_new_prescaling <= '0'; int_read_rates <= '0'; - int_read_DACs <= '0'; - int_read_enables <= '0'; + int_read_DACs <= '0'; + int_read_enables <= '0'; int_read_prescaling <= '0'; int_ping_pong <= '0'; Index: firmware/FTU/rs485/FTU_rs485_receiver.vhd =================================================================== --- firmware/FTU/rs485/FTU_rs485_receiver.vhd (revision 10037) +++ firmware/FTU/rs485/FTU_rs485_receiver.vhd (revision 10047) @@ -10,4 +10,5 @@ -- -- modified for FTU design by Q. Weitzel, 13 September 2010 +-- timeout added, Q. Weitzel, 26 October 2010 -- @@ -36,25 +37,43 @@ ARCHITECTURE beha OF FTU_rs485_receiver IS - signal rxcnt : integer range 0 to RX_BYTES := 0; - signal rxsr : std_logic_vector(3 downto 0) := (others => '0'); + signal rxcnt : integer range 0 to RX_BYTES := 0; + signal rxsr : std_logic_vector(3 downto 0) := (others => '0'); + signal timeout_cnt : integer range 0 to RS485_TIMEOUT + 1 := 0; BEGIN - rx_data_proc: process (rec_clk) + rx_data_proc : process(rec_clk) begin if rising_edge(rec_clk) then rxsr <= rxsr(2 downto 0) & rec_den; - if (rxsr(3 downto 2) = "01") then -- identify rising edge - rec_dout((rxcnt*rec_din'length + rec_din'length - 1) downto (rxcnt*rec_din'length)) <= rec_din; - rxcnt <= rxcnt + 1; - if (rxcnt < RX_BYTES - 1) then - rec_valid <= '0'; - else - rxcnt <= 0; - rec_valid <= '1'; + if (timeout_cnt = RS485_TIMEOUT) then + rec_dout <= (others => '0'); + rxcnt <= 0; + rec_valid <= '0'; + else + if (rxsr(3 downto 2) = "01") then -- identify rising edge + rec_dout((rxcnt*rec_din'length + rec_din'length - 1) downto (rxcnt*rec_din'length)) <= rec_din; + rxcnt <= rxcnt + 1; + if (rxcnt < RX_BYTES - 1) then + rec_valid <= '0'; + else + rxcnt <= 0; + rec_valid <= '1'; + end if; end if; end if; + end if; + end process rx_data_proc; + + rx_timeout_proc : process(rec_clk) + begin + if rising_edge(rec_clk) then + if (rxcnt > 0) then + timeout_cnt <= timeout_cnt + 1; + else + timeout_cnt <= 0; + end if; end if; - end process rx_data_proc; - + end process rx_timeout_proc; + END ARCHITECTURE beha;