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

Last change on this file since 14788 was 10010, checked in by weitzel, 14 years ago
FTU documentation v1 added
File size: 23.7 KB
Line 
1\documentclass[a4paper,11pt]{report}
2
3\usepackage{float}
4\usepackage{graphicx}
5\usepackage{url}
6\usepackage[T1]{fontenc}
7\usepackage{amsmath}
8\usepackage{longtable}
9\usepackage{parskip}
10\usepackage{pifont}
11\usepackage{array}
12
13\setlength{\oddsidemargin}{0cm}
14\setlength{\evensidemargin}{0cm}
15\setlength{\topmargin}{0cm}
16
17\textwidth 6.2in
18\textheight 9in
19\columnsep 0.25in
20
21\pagestyle{plain}
22\setcounter{tocdepth}{1}
23
24\title{\vspace*{-7cm} \Huge \bf FTU Firmware Specifications}
25\author{\Large Quirin Weitzel\footnote{Contact for questions and suggestions concerning this
26 document: {\tt qweitzel@phys.ethz.ch}}, Patrick Vogler}
27\date{\vspace*{0.5cm} \Large v1~~~-~~~September 2010}
28
29\begin{document}
30
31\maketitle
32
33\newpage
34
35\tableofcontents
36
37\chapter{Introduction}
38
39The FACT Trigger Unit (FTU) is a Mezzanine Card attached to the FACT
40Pre-Amplifier (FPA) board. On the FPA, the analog signals of nine adjacent
41pixels are summed up, and the total signal is compared to a threshold. Four
42such trigger patches are hosted by one FPA. The corresponding four digital
43trigger signals are processed further by the FTU, generating a single trigger
44primitive out of them. A total of 40 FTU boards exists in the FACT
45camera. Their trigger primitives are collected at one central point, the FACT
46Trigger Master (FTM)\footnote{For more information about the FACT trigger
47 system see: P.~Vogler, {\it Development of a trigger system for a Cherenkov
48 Telescope Camera based on Geiger-mode avalanche photodiodes}, Master
49 Thesis, ETH Zurich, 2010.}. The FTM serves also as slow control master for
50the FTUs, which are connected in groups of ten to RS485 data buses for this
51purpose. These buses are realized on the midplanes of the four crates inside
52the camera.
53
54The main component on each FTU is a FPGA\footnote{Xilinx Spartan-3AN family
55 (XC3S400AN-4FGG400C); for programming information see:
56 \url{http://www.xilinx.com/support/documentation/user_guides/ug331.pdf}
57 (Spartan-3 Generation FPGA User Guide).}, fulfilling different tasks within
58the board. The purpose of this document is to describe the main features of
59the firmware of this device, which is identical for all 40 boards. After a
60brief summary of the FTU functionality and its digital components, a general
61overview of the firmware design is given. In the following, all FPGA registers
62available for reading and writing are listed. Afterwards the communication
63with the FTM is detailed, and the most important finite state machines
64implemented are explained.
65
66\chapter{FTU Tasks and Digital Components}
67
68In order to define the thresholds for the individual trigger patches, four
69channels of an octal \mbox{12-bit} Digital-to-Analog Converter (DAC) are
70used. This chip\footnote{Details concerning specific electronics components as
71 well as schematics can be found at the FACT construction page:
72 \url{http://ihp-pc1.ethz.ch/FACT} (password protected).} is accessed by the
73FPGA through a Serial Peripheral Interface (SPI). A fifth channel of the same
74DAC is employed to control a $n$-out-of-4 majority coincidence logic,
75generating the trigger primitive out of the patch signals. The FTU can
76furthermore switch off single pixels within the trigger patches by disabling
77the corresponding input buffers just before the summation stage on the
78FPA. However, the decision to switch off a pixel for the trigger or to change
79the threshold for a patch is not taken by the FTU itself, but has to come in
80form of a command from the FTM.
81
82For each of the four trigger patches, the FTU counts the number of triggers
83within a certain time period. Also the number of trigger primitives after the
84$n$-out-of-4 majority coincidence is counted. In this way, the rates per patch
85and per board are known for each FTU. The counters are implemented inside the
86FPGA with a range of 16\,bit. In case the number of triggers exceeds this
87limit, an overflow flag is set. The counting period is changeable from outside
88between 500\,ms and 128\,s with a resolution of 8\,bit.
89
90Each FTU board has one RS485 communication interface to the FTM. Ten boards
91are connected to one bus, where they are operated in slave-mode. Only in case
92a read or write command for a specific FTU arrives from the FTM, this board
93will react and answer. Broadcast commands are not supported by the current
94firmware version. To avoid data collisions on the buses, the FTM has to
95address the FTUs one by one to read out the rates for example. A RS485
96interface is implemented inside the FPGA, including frame receiving, data
97buffering and instruction decoding. It is minimal in the sense that no stacked
98commands, command buffering or interrupts are supported. Outside the FPGA, a
99RS485 driver/receiver chip translates the signal levels between the
100differential bus lines and the FPGA logic levels. This chip is enabled for
101data transmission or data receiving, respectively.
102
103\chapter{Firmware Organization}
104\label{cha:organization}
105
106The FTU firmware is written in VHDL (VHSIC Hardware Description Language). For
107some of its components the Xilinx core generator tools\footnote{Xilinx ISE
108 Design Suite, release 11.5, homepage: \url{http://www.xilinx.com}
109 (downloads, documentation).} have been used. In this chapter, an overview of
110the firmware content is given, followed by a listing of the files containing
111the source code. The complete project is available from the FACT
112repository\footnote{Project page: \url{https://fact.isdc.unige.ch/trac}
113 (password protected).}.
114
115\section{Design Overview}
116\label{sec:organization:design}
117
118The highest level entity in the firmware is called {\tt FTU\_top}. Its ports
119are the physical connections of the FPGA on the FTU board. Inside {\tt
120 FTU\_top} other entities are instantiated, representing different functional
121modules. They are discussed in the following subsections. For important
122numbers and constants the package {\tt ftu\_constants} inside the library {\tt
123 ftu\_definitions} has been created. A second package {\tt ftu\_array\_types}
124contains customized array types.
125
126\subsection{\tt FTU\_clk\_gen}
127
128This is an interface to the Digital Clock Managers (DCM) of the FPGA. At the
129moment only one DCM is used, providing the central 50\,MHz clock. Once the DCM
130has locked and is providing a stable frequency {\tt FTU\_clk\_gen} sends a
131ready signal. This is a prerequisite for the board to enter the {\tt RUNNING}
132state. Some modules within the FTU design have built-in clock dividers to
133generate custom frequencies which are, however, all derived from the central
134clock.
135
136\subsection{\tt FTU\_dual\_port\_ram}
137\label{sec:organization:design:ram}
138
139All FTU registers which can be set from outside during operation are stored in
140a dual-port block RAM (Random Access Memory). The FPGA provides specific
141resources for this purpose, and therefore the RAM has been created using the
142Xilinx core generator tools. The entity {\tt FTU\_dual\_port\_ram} serves as
143an interface to the RAM, the actual gate level description is stored directly
144in the net-list file {\tt FTU\_dual\_port\_ram.ngc}. Thus this file is part of
145the design, although not available as source code. The RAM has a size of
14632\,bytes and two fully featured ports to access its content. One port is
147based on 1-byte words, the other one on 2-byte words. The corresponding
148address space is presented together with the register tables in
149chapter~\ref{cha:registers}. In addition to the control registers, also the
150current counter readings are stored in the RAM.
151
152\subsection{\tt FTU\_rate\_counter}
153\label{sec:organization:design:counter}
154
155Here the trigger counting is done. A rate counter has a range of 16\,bit and
156counts until a defined period is finished. This period is derived from an
1578-bit prescaling value $y$ as $ T = \frac{y+1}{2}$\,s. In total five such
158counters are instantiated which are running and set up synchronously. If the
159FTU settings are changed during operation all counters are reset. Only in case
160a full period has been finished without interruption, the number of counts
161from each counter is stored in the RAM. An overflow flag is set by the
162counters if necessary.
163
164\subsection{\tt FTU\_spi\_interface}
165
166The octal DAC defining the trigger thresholds is controlled by means of a
167SPI. As soon as the {\tt FTU\_spi\_interface} entity receives a start signal,
168it will clock out the data pending at one of its input ports to the DAC. These
169data are provided in form of a customized array. The generation of the serial
170clock, the distribution of the DAC values to the right addresses and the
171actual transmission of the data to the chip are performed by three more
172entities, which are instantiated inside {\tt FTU\_spi\_interface}. Once the
173transmission has started or finished, respectively, a signal is pulled.
174
175\subsection{\tt FTU\_rs485\_control}
176
177The communication between the FTU and the FTM is handled by a RS485
178interface. The top level entity of this module is called {\tt
179 FTU\_rs485\_control}. It contains a state machine and further sub-entities
180for frame receiving or transmitting, byte buffering and instruction
181decoding. The details of the underlying protocol and the possible instructions
182are detailed in chapter~\ref{cha:communication}. In case an instruction has
183been decoded successfully, the main FTU control is informed and the
184corresponding data (like new DAC values) are provided. After the command has
185been executed an answer is send to the FTM. {\tt FTU\_rs485\_control} has
186direct control of the involved transmitter/receiver chip outside the FPGA and
187takes care that it is only transmitting if this particular FTU has been
188contacted by the FTM. In this way also the rates are send on request. The baud
189rate is adjustable and defined in the library {\tt ftu\_definitions}.
190
191\subsection{\tt FTU\_control}
192
193This entity contains the main state machine of the FTU firmware. It receives
194control, ready, start, etc. flags from all modules and interfaces and reacts
195accordingly by changing to a new state. This may be done with some delay,
196depending on what the board is doing at the moment. {\tt FTU\_control} is
197furthermore the only place in the design from where the RAM is read or
198written. The state machine is described in more detail in
199chapter~\ref{cha:fsm}.
200
201\section{File Structure}
202
203Table~\ref{tab:files} specifies all source files necessary to compile the
204firmware for the FTU boards\footnote{As of September 2010; the list might be
205 extended, for example, to include source files for the read out of the FPGA
206 serial number (device ID).}. For each file its location path inside the
207directory {\tt firmware} of the FACT repository is stated. Furthermore it is
208indicated whether a certain file is needed for the simulation and/or the
209hardware implementation. The design entities described in
210section~\ref{sec:organization:design} are contained in those files which have
211the corresponding prefix. The file {\tt ucrc\_par.vhd} has been downloaded
212from OpenCores\footnote{Ultimate CRC project:
213 \url{http://www.opencores.org/cores/ultimate_crc} (free software under the
214 terms of the GNU General Public License).}.
215
216\begin{table}[htbp]
217 \centering
218 \begin{tabular}{|l|l|l|l|l|}
219 \hline
220 file name & location & simulation & implement & comment \\
221 \hline\hline
222 {\tt FTU\_top.vhd} & {\tt FTU} & yes & yes & top level entity\\
223 \hline
224 {\tt FTU\_top\_tb.vhd} & {\tt FTU} & yes & no & test bench\\
225 \hline
226 {\tt ftu\_definitions.vhd} & {\tt FTU} & yes & yes & library\\
227 \hline
228 {\tt ftu\_board.ucf} & {\tt FTU} & no & yes & pin constraints\\
229 \hline
230 {\tt FTU\_control.vhd} & {\tt FTU} & yes & yes & top state machine\\
231 \hline\hline
232 {\tt FTU\_clk\_gen.vhd} & {\tt FTU/clock} & yes & yes & clock interface\\
233 \hline
234 {\tt FTU\_dcm\_50M\_to\_50M.vhd} & {\tt FTU/clock} & yes & yes & clock manager\\
235 \hline\hline
236 {\tt FTU\_rate\_counter.vhd} & {\tt FTU/counter} & yes & yes & trigger counter\\
237 \hline\hline
238 {\tt FTU\_spi\_interface.vhd} & {\tt FTU/dac\_spi} & yes & yes & SPI top entity\\
239 \hline
240 {\tt FTU\_spi\_clock\_gen.vhd} & {\tt FTU/dac\_spi} & yes & yes & serial clock\\
241 \hline
242 {\tt FTU\_distributor.vhd} & {\tt FTU/dac\_spi} & yes & yes & DAC loop\\
243 \hline
244 {\tt FTU\_controller.vhd} & {\tt FTU/dac\_spi} & yes & yes & low level SPI\\
245 \hline\hline
246 {\tt FTU\_dual\_port\_ram.vhd} & {\tt FTU/ram} & yes & yes & RAM interface\\
247 \hline
248 {\tt FTU\_dual\_port\_ram.ngc} & {\tt FTU/ram} & no & yes & RAM netlist\\
249 \hline\hline
250 {\tt FTU\_rs485\_control.vhd} & {\tt FTU/rs485} & yes & yes & RS485 top entity\\
251 \hline
252 {\tt FTU\_rs485\_interpreter.vhd} & {\tt FTU/rs485} & yes & yes & data decoding\\
253 \hline
254 {\tt FTU\_rs485\_receiver.vhd} & {\tt FTU/rs485} & yes & yes & 16~byte buffer\\
255 \hline
256 {\tt FTU\_rs485\_interface.vhd} & {\tt FTU/rs485} & yes & yes & low level RS485\\
257 \hline
258 {\tt ucrc\_par.vhd} & {\tt FTU/rs485} & yes & yes & check sum\\
259 \hline
260 \end{tabular}
261 \caption{List of all source files needed to compile the FTU firmware.}
262 \label{tab:files}
263\end{table}
264
265\chapter{Register Tables}
266\label{cha:registers}
267
268There are 31 control and rate registers implemented in the FTU firmware, each
269with a size of 8\,bit. They are organized as a 32-byte RAM (see also
270section~\ref{sec:organization:design:ram}), the last byte of which is empty
271and serves as spare. Table~\ref{tab:RAM} presents an overview of the address
272space inside the RAM, more details can be found in tables~\ref{tab:enables} -
273\ref{tab:overflow}. Registers marked as read-only cannot be written by the
274FTM, but are updated by the FTU itself.
275
276\begin{table}[htbp]
277 \centering
278 \begin{tabular}{|c|l|l|}
279 \hline
280 RAM address & register block & comment\\
281 \hline\hline
282 $0 \dots 7$ & enable patterns & read/write\\
283 \hline
284 $8 \dots 17$ & rate counters & read-only\\
285 \hline
286 $18 \dots 27$ & DAC settings & read/write\\
287 \hline
288 $28$ & prescaling $y$ (see section~\ref{sec:organization:design:counter}) & read/write \\
289 \hline
290 $29$ & overflow bits & read-only \\
291 \hline
292 $30$ & check sum error counter & read-only\\
293 \hline
294 $31$ & empty & spare \\
295 \hline
296 \end{tabular}
297 \caption{Overview of the register mapping inside the RAM.}
298 \label{tab:RAM}
299\end{table}
300
301\section{Enable Patterns}
302
303\begin{table}[htbp]
304 \centering
305 %\small
306 \begin{tabular}{|c||l|l|l|l|l|l|l|l|}
307 \hline
308 address & bit~7 & bit~6 & bit~5 & bit~4 & bit~3 & bit~2 & bit~1 & bit~0 \\
309 \hline\hline
310 00 & En\_A7 & En\_A6 & En\_A5 & En\_A4 & En\_A3 & En\_A2 & En\_A1 &
311 En\_A0 \\
312 \hline
313 01 & \- & \- & \- & \- & \- & \- & \- & En\_A8 \\
314 \hline
315 02 & En\_B7 & En\_B6 & En\_B5 & En\_B4 & En\_B3 & En\_B2 & En\_B1 &
316 En\_B0 \\
317 \hline
318 03 & \- & \- & \- & \- & \- & \- & \- & En\_B8 \\
319 \hline
320 04 & En\_C7 & En\_C6 & En\_C5 & En\_C4 & En\_C3 & En\_C2 & En\_C1 &
321 En\_C0 \\
322 \hline
323 05 & \- & \- & \- & \- & \- & \- & \- & En\_C8 \\
324 \hline
325 06 & En\_D7 & En\_D6 & En\_D5 & En\_D4 & En\_D3 & En\_D2 & En\_D1 &
326 En\_D0 \\
327 \hline
328 07 & \- & \- & \- & \- & \- & \- & \- & En\_D8\\
329 \hline
330 \end{tabular}
331 \caption{Mapping of the $4 \times 9$ enable bits inside the RAM.}
332 \label{tab:enables}
333\end{table}
334
335\section{Rate Counters}
336
337\begin{table}[htbp]
338 \centering
339 %\small
340 \begin{tabular}{|c||l|l|l|l|l|l|l|l|}
341 \hline
342 address & bit~7 & bit~6 & bit~5 & bit~4 & bit~3 & bit~2 & bit~1 & bit~0 \\
343 \hline\hline
344 08 & Ct\_A7 & Ct\_A6 & Ct\_A5 & Ct\_A4 & Ct\_A3 & Ct\_A2 & Ct\_A1 & Ct\_A0 \\
345 \hline
346 09 & Ct\_A15 & Ct\_A14 & Ct\_A13 & Ct\_A12 & Ct\_A11 & Ct\_A10 & Ct\_A9 & Ct\_A8 \\
347 \hline
348 10 & Ct\_B7 & Ct\_B6 & Ct\_B5 & Ct\_B4 & Ct\_B3 & Ct\_B2 & Ct\_B1 & Ct\_B0 \\
349 \hline
350 11 & Ct\_B15 & Ct\_B14 & Ct\_B13 & Ct\_B12 & Ct\_B11 & Ct\_B10 & Ct\_B9 & Ct\_B8 \\
351 \hline
352 12 & Ct\_C7 & Ct\_C6 & Ct\_C5 & Ct\_C4 & Ct\_C3 & Ct\_C2 & Ct\_C1 & Ct\_C0 \\
353 \hline
354 13 & Ct\_C15 & Ct\_C14 & Ct\_C13 & Ct\_C12 & Ct\_C11 & Ct\_C10 & Ct\_C9 & Ct\_C8 \\
355 \hline
356 14 & Ct\_D7 & Ct\_D6 & Ct\_D5 & Ct\_D4 & Ct\_D3 & Ct\_D2 & Ct\_D1 & Ct\_D0 \\
357 \hline
358 15 & Ct\_D15 & Ct\_D14 & Ct\_D13 & Ct\_D12 & Ct\_D11 & Ct\_D10 & Ct\_D9 & Ct\_D8 \\
359 \hline
360 16 & Ct\_T7 & Ct\_T6 & Ct\_T5 & Ct\_T4 & Ct\_T3 & Ct\_T2 & Ct\_T1 & Ct\_T0 \\
361 \hline
362 17 & Ct\_T15 & Ct\_T14 & Ct\_T13 & Ct\_T12 & Ct\_T11 & Ct\_T10 & Ct\_T9 & Ct\_T8 \\
363 \hline
364 \end{tabular}
365 \caption{Mapping of the four patch counters and the trigger counter inside the RAM.}
366 \label{tab:rates}
367\end{table}
368
369\section{DAC Settings}
370
371\begin{table}[htbp]
372 \centering
373 \begin{tabular}{|c|l|}
374 \hline
375 address & data[$7 \dots 0$]\\
376 \hline\hline
377 18 & DAC\_A\_[$7 \dots 0$] \\
378 \hline
379 19 & DAC\_A\_[$15 \dots 8$] \\
380 \hline
381 20 & DAC\_B\_[$7 \dots 0$] \\
382 \hline
383 21 & DAC\_B\_[$15 \dots 8$] \\
384 \hline
385 22 & DAC\_C\_[$7 \dots 0$] \\
386 \hline
387 23 & DAC\_C\_[$15 \dots 8$] \\
388 \hline
389 24 & DAC\_D\_[$7 \dots 0$] \\
390 \hline
391 25 & DAC\_D\_[$15 \dots 8$] \\
392 \hline
393 26 & DAC\_H\_[$7 \dots 0$] \\
394 \hline
395 27 & DAC\_H\_[$15 \dots 8$] \\
396 \hline
397 \end{tabular}
398 \caption{Mapping of the DAC values (12\,bit) for the thresholds (DAC\_A -- DAC\_D) and the
399 $n$-out-of-4 logic (DAC\_H) inside the RAM; the bits $15\dots 12$ are filled up with zeros.}
400 \label{tab:dacs}
401\end{table}
402
403\section{Overflow Bits}
404
405\begin{table}[htbp]
406 \centering
407 \begin{tabular}{|l|c|c|c|c|c|c|}
408 \hline
409 bit & $7 \dots 5$ & 4 & 3 & 2 & 1 & 0 \\
410 \hline\hline
411 0 & not used & overflow\_T & overflow\_D & overflow\_C & overflow\_B & overflow\_A \\
412 \hline
413 \end{tabular}
414 \caption{Bit mapping inside the RAM overflow register (address 29).}
415 \label{tab:overflow}
416\end{table}
417
418\chapter{Communication with FTM}
419\label{cha:communication}
420
421The slow control system between the FTU boards (slaves) and the FTM (master)
422is based on two transmission sequences: Either the FTM is sending data to a
423particular FTU, or a particular FTU is answering to the FTM. Broadcast
424commands are not supported. Each board has an unique 1-byte address for
425unambiguous identification, which is 0--39 for the FTUs and 192 for the
426FTM. The transmission sequences are of fixed length (16\,byte) and, if
427necessary, filled up with arbitrary data. In case the data transmission is
428disturbed or not complete, a time-out system ensures that the communication
429doesn't get stuck\footnote{At a baud rate of 250\,kHz, for example, this
430 time-out is set to 2\,ms on the FTU side.}. In the following, the slow
431control protocol, the instruction codes and the check sum error-detection are
432discussed.
433
434\section{Transmission Protocol}
435
436Table~\ref{tab:protocol} summarizes the structure of the data sequences sent
437between the FTM and the FTUs. An FTU only replies if contacted by the FTM. The
438answer is a copy of the received data package with swapped source/destination
439address and eventually the requested data.
440
441\begin{table}[htbp]
442 \centering
443 \begin{tabular}{|c|l|l|}\hline
444 byte & content & comment \\
445 \hline\hline
446 0 & start delimiter & ASCI @ (binary "01000000")\\
447 \hline
448 1 & destination address & 192 (FTM) or slot position 0--39 (FTUs)\\
449 \hline
450 2 & source address & 192 (FTM) or slot position 0--39 (FTUs)\\
451 \hline
452 3 & instruction / info & see section~\ref{cha:communication:instr}\\
453 \hline
454 4--14 & 11 byte data & DACs, rates, etc.\\
455 \hline
456 15 & check sum & CRC-8-CCITT, see section~\ref{cha:communication:crc}\\
457 \hline
458 \end{tabular}
459 \caption{Composition of the FTM-FTU slow control data packages.}
460 \label{tab:protocol}
461\end{table}
462
463\section{Instruction Table}
464\label{cha:communication:instr}
465
466A set of eight instructions has been foreseen for the communication between
467the FTM and the FTUs. They are listed in table~\ref{tab:instructions}
468including a short description. For the ping-pong command it is currently
469investigated whether the FTUs can, in addition to just answer, return also the
470FPGA device identifier\footnote{This unique identifier has 57\,bit and is
471 built-in for each FPGA of the Spartan-3A series. For more information see:
472 \url{http://www.xilinx.com/support/documentation/user_guides/ug332.pdf}
473 (Spartan-3 Generation Configuration User Guide).} (DNA).
474
475\begin{table}[htbp]
476 \centering
477 \begin{tabular}{|c|l|l|}
478 \hline
479 code & instruction & description \\
480 \hline\hline
481 00 & set DAC & write new values into DAC registers \\
482 \hline
483 01 & read DAC & read back content of DAC registers \\
484 \hline
485 02 & read rates & read out rates and overflow bits \\
486 \hline
487 03 & set enable & write new patterns into enable registers \\
488 \hline
489 04 & read enable & read back content of enable registers \\
490 \hline
491 05 & ping-pong & ping a FTU to check communication (see text)\\
492 \hline
493 06 & set counter mode & write into the prescaling register \\
494 \hline
495 07 & read counter mode & read back prescaling and overflow registers \\
496 \hline
497 \end{tabular}
498 \caption{Instruction set for the FTM-FTU slow control communication.}
499 \label{tab:instructions}
500\end{table}
501
502\section{CRC Calculation}
503\label{cha:communication:crc}
504
505The integrity of the 16-byte data packages is evaluated by means of a Cyclic
506Redundancy Check (CRC). An 8-CCITT CRC has been chosen which is based on the
507polynomial $x^8 + x^2 + x + 1$ (100000111). Bytes 0--14 of
508table~\ref{tab:protocol} constitute the input vector for the CRC calculation,
509the resulting 1-byte check sum being compared with the one transmitted by the
510FTM (byte 15 in table~\ref{tab:protocol}). If the check sum turns out to be
511wrong, the FTU doesn't answer and increases the number of error counts in its
512corresponding register (RAM address 30). The FTM will consequently run into a
513time-out and repeat its command.
514
515\chapter{Finite State Machines}
516\label{cha:fsm}
517
518There are several finite state machines (FSM) used in the FTU firmware design,
519distributed over several files. They are in principal all running in parallel,
520some of them are, however, only waking up if triggered by the main
521control. This is for example the case for the SPI interface controlling the
522DAC settings. Since the most complicated FSMs are inside {\tt FTU\_control}
523and {\tt FTU\_rs485\_control} (see section~\ref{sec:organization:design}),
524they are explained in more detail in this chapter.
525
526\section{Main Control FSM}
527
528This state machine has full control over the FTU board during operation. After
529power-up or reboot it is in an {\tt IDLE} state, waiting for the DCMs to
530lock. Afterwards it passes through an {\tt INIT} sequence, where default
531values for all registers are written to the RAM. These defaults are all
532defined in the library {\tt ftu\_definitions}. When {\tt INIT} has finished,
533the {\tt RUNNING} state is entered. This is the principal state during which
534the board is counting triggers. {\tt RUNNING} is left only if a counting
535period has finished and the number of counts is stored in the RAM, or if a
536command has arrived via RS485 and is communicated by the responsible FSM (see
537next section). A dedicated state has been implemented for each possible
538command and, if appropriate, also for the subsequent change of settings
539(e.g. {\tt CONFIG\_DAC}). In any case the board goes back to {\tt RUNNING}.
540
541\section{RS485 Control FSM}
542
543The main and default state of this FSM is {\tt RECEIVE}. This means that the
544RS485 receiver is enabled and the board is waiting for commands from the
545FTM. If a full 16-byte package has arrived and correctly been
546decoded\footnote{This involves a further state machine which is inside the
547 file {\tt FTU\_rs485\_interpreter.vhd}}, the main control FSM is informed
548about the instruction (e.g. new DACs). The RS485 FSM then enters a wait state
549(e.g. {\tt SET\_DAC\_WAIT}) until it gets an internal ready signal. It
550subsequently sends the answer to the FTM (e.g. {\tt SET\_DAC\_TRANSMIT}) and
551goes back to {\tt RECEIVE}. While during {\tt RECEIVE} the RS485 FSM and all
552processes below are running in parallel to the main control FSM, the sequence
553of states in case a command has arrived is prescribed.
554
555\end{document}
Note: See TracBrowser for help on using the repository browser.