Index: firmware/FTU/doc/v3/FTU_firmware_v3.tex =================================================================== --- firmware/FTU/doc/v3/FTU_firmware_v3.tex (revision 10057) +++ firmware/FTU/doc/v3/FTU_firmware_v3.tex (revision 10057) @@ -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 v3~~~-~~~November 2010} + +\begin{document} + +\maketitle + +\newpage + +\tableofcontents + +\chapter{Introduction} + +The FACT Trigger Unit (FTU) is a Mezzanine Card attached to the FACT +Pre-Amplifier (FPA) board. On the FPA, the analog signals of nine adjacent +pixels are summed up, and the total signal is compared to a threshold. Four +such trigger patches are hosted by one FPA. The corresponding four digital +trigger signals are processed further by the FTU, generating a single trigger +primitive out of them. A total of 40 FTU boards exists in the FACT +camera. Their trigger primitives are collected at one central point, the FACT +Trigger Master (FTM)\footnote{For more information about the FACT trigger + system see: P.~Vogler, {\it Development of a trigger system for a Cherenkov + Telescope Camera based on Geiger-mode avalanche photodiodes}, Master + Thesis, ETH Zurich, 2010.}. The FTM serves also as slow control master for +the FTUs, which are connected in groups of ten to RS485 data buses for this +purpose. These buses are realized on the midplanes of the four crates inside +the camera. + +The main component on each FTU is a FPGA\footnote{Xilinx Spartan-3AN family + (XC3S400AN-4FGG400C); for programming information see: + \url{http://www.xilinx.com/support/documentation/user_guides/ug331.pdf} + (Spartan-3 Generation FPGA User Guide).}, fulfilling different tasks within +the board. The purpose of this document is to describe the main features of +the firmware of this device, which is identical for all 40 boards. After a +brief summary of the FTU functionality and its digital components, a general +overview of the firmware design is given. In the following, all FPGA registers +available for reading and writing are listed. Afterwards the communication +with the FTM is detailed, and the most important finite state machines +implemented are explained. + +\chapter{FTU Tasks and Digital Components} + +In order to define the thresholds for the individual trigger patches, four +channels of an octal \mbox{12-bit} Digital-to-Analog Converter (DAC) are +used. This chip\footnote{Details concerning specific electronics components as + well as schematics can be found at the FACT construction page: + \url{http://ihp-pc1.ethz.ch/FACT} (password protected).} is accessed by the +FPGA through a Serial Peripheral Interface (SPI). A fifth channel of the same +DAC is employed to control a $n$-out-of-4 majority coincidence logic, +generating the trigger primitive out of the patch signals. The FTU can +furthermore switch off single pixels within the trigger patches by disabling +the corresponding input buffers just before the summation stage on the +FPA. However, the decision to switch off a pixel for the trigger or to change +the threshold for a patch is not taken by the FTU itself, but has to come in +form of a command from the FTM. + +For each of the four trigger patches, the FTU counts the number of triggers +within a certain time period. Also the number of trigger primitives after the +$n$-out-of-4 majority coincidence is counted. In this way, the rates per patch +and per board are known for each FTU. The counters are implemented inside the +FPGA with a range of 30\,bit. In case the number of triggers exceeds this +limit, an overflow flag is set. The counting period is changeable from outside +between 500\,ms and 128\,s with a resolution of 8\,bit. + +Each FTU board has one RS485 communication interface to the FTM. Ten boards +are connected to one bus, where they are operated in slave-mode. Only in case +a read or write command for a specific FTU arrives from the FTM, this board +will react and answer. Broadcast commands are not supported by the current +firmware version. To avoid data collisions on the buses, the FTM has to +address the FTUs one by one to read out the rates for example. A RS485 +interface is implemented inside the FPGA, including frame receiving, data +buffering and instruction decoding. It is minimal in the sense that no stacked +commands, command buffering or interrupts are supported. Outside the FPGA, a +RS485 driver/receiver chip translates the signal levels between the +differential bus lines and the FPGA logic levels. This chip is enabled for +data transmission or data receiving, respectively. + +\chapter{Firmware Organization} +\label{cha:organization} + +The FTU firmware is written in VHDL (VHSIC Hardware Description Language). For +some of its components the Xilinx core generator tools\footnote{Xilinx ISE + Design Suite, release 11.5, homepage: \url{http://www.xilinx.com} + (downloads, documentation).} have been used. In this chapter, an overview of +the firmware content is given, followed by a listing of the files containing +the source code. The complete project is available from the FACT +repository\footnote{Project page: \url{https://fact.isdc.unige.ch/trac} + (password protected).}. + +\section{Design Overview} +\label{sec:organization:design} + +The highest level entity in the firmware is called {\tt FTU\_top}. Its ports +are the physical connections of the FPGA on the FTU board. Inside {\tt + FTU\_top} other entities are instantiated, representing different functional +modules. They are discussed in the following subsections. For important +numbers and constants the package {\tt ftu\_constants} inside the library {\tt + ftu\_definitions} has been created. A second package {\tt ftu\_array\_types} +contains customized array types. + +\subsection{\tt FTU\_clk\_gen} + +This is an interface to the Digital Clock Managers (DCM) of the FPGA. At the +moment only one DCM is used, providing the central 50\,MHz clock. Once the DCM +has locked and is providing a stable frequency {\tt FTU\_clk\_gen} sends a +ready signal. This is a prerequisite for the board to enter the {\tt RUNNING} +state. {\tt FTU\_clk\_gen} also generates a central 1\,MHz clock for the rate +counters (by division, not using a second DCM). In addition, some modules +within the FTU design have their own built-in clock dividers to generate +custom frequencies. + +\subsection{\tt FTU\_dual\_port\_ram64} +\label{sec:organization:design:ram} + +All FTU registers which can be set from outside during operation are stored in +a dual-port block RAM (Random Access Memory). The FPGA provides specific +resources for this purpose, and therefore the RAM has been created using the +Xilinx core generator tools. The entity {\tt FTU\_dual\_port\_ram64} serves as +an interface to the RAM, the actual gate level description is stored directly +in the net-list file {\tt FTU\_dual\_port\_ram64.ngc}. Thus this file is part +of the design, although not available as source code. The RAM has a size of +64\,bytes and two fully featured ports to access its content. One port is +based on 1-byte words, the other one on 2-byte words. The corresponding +address space is presented together with the register tables in +chapter~\ref{cha:registers}. In addition to the control registers, also the +current counter readings are stored in the RAM. + +\subsection{\tt FTU\_rate\_counter} +\label{sec:organization:design:counter} + +Here the trigger counting is done. A rate counter has a range of 30\,bit and +counts until a defined period is finished. This period is derived from an +8-bit prescaling value $y$ as $ T = \frac{y+1}{2}$\,s. In total five such +counters are instantiated which are running and set up synchronously. If the +FTU settings are changed during operation all counters are reset. Only in case +a full period has been finished without interruption, the number of counts +from each counter is stored in the RAM. An overflow flag is set by the +counters if necessary. + +\subsection{\tt FTU\_spi\_interface} + +The octal DAC defining the trigger thresholds is controlled by means of a +SPI. As soon as the {\tt FTU\_spi\_interface} entity receives a start signal, +it will clock out the data pending at one of its input ports to the DAC. These +data are provided in form of a customized array. The generation of the serial +clock, the distribution of the DAC values to the right addresses and the +actual transmission of the data to the chip are performed by three more +entities, which are instantiated inside {\tt FTU\_spi\_interface}. Once the +transmission has started or finished, respectively, a signal is pulled. + +\subsection{\tt FTU\_rs485\_control} + +The communication between the FTU and the FTM is handled by a RS485 +interface. The top level entity of this module is called {\tt + FTU\_rs485\_control}. It contains a state machine and further sub-entities +for frame receiving or transmitting, byte buffering and instruction +decoding. The details of the underlying protocol and the possible instructions +are detailed in chapter~\ref{cha:communication}. In case an instruction has +been decoded successfully, the main FTU control is informed and the +corresponding data (like new DAC values) are provided. After the command has +been executed an answer is send to the FTM. {\tt FTU\_rs485\_control} has +direct control of the involved transmitter/receiver chip outside the FPGA and +takes care that it is only transmitting if this particular FTU has been +contacted by the FTM. In this way also the rates are send on request. The baud +rate is adjustable and defined in the library {\tt ftu\_definitions}. + +\subsection{\tt FTU\_control} + +This entity contains the main state machine of the FTU firmware. It receives +control, ready, start, etc. flags from all modules and interfaces and reacts +accordingly by changing to a new state. This may be done with some delay, +depending on what the board is doing at the moment. {\tt FTU\_control} is +furthermore the only place in the design from where the RAM is read or +written. The state machine is described in more detail in +chapter~\ref{cha:fsm}. + +\subsection{\tt FTU\_dna\_gen} +\label{sec:organization:design:dna} + +In order to be able to unambiguously identify each FTU during operation, the +device identifier\footnote{This unique identifier has 57\,bit and is built-in + for each FPGA of the Spartan-3A series. For more information see: + \url{http://www.xilinx.com/support/documentation/user_guides/ug332.pdf} + (Spartan-3 Generation Configuration User Guide).} (DNA) of its FPGA is +used. After power-up this DNA is read-out once by {\tt FTU\_dna\_gen} and +stored for later usage inside {\tt FTU\_top} as a permanent signal. + +\section{File Structure} + +Table~\ref{tab:files} specifies all source files necessary to compile the +firmware for the FTU boards\footnote{As of November 2010; the file structure + might still be changed.}. For each file its location path inside the +directory {\tt firmware} of the FACT repository is stated. Furthermore it is +indicated whether a certain file is needed for the simulation and/or the +hardware implementation. The design entities described in +section~\ref{sec:organization:design} are contained in those files which have +the corresponding prefix. The file {\tt ucrc\_par.vhd} has been downloaded +from OpenCores\footnote{Ultimate CRC project: + \url{http://www.opencores.org/cores/ultimate_crc} (free software under the + terms of the GNU General Public License).}. + +\begin{table}[htbp] + \centering + \begin{tabular}{|l|l|l|l|l|} + \hline + file name & location & simulation & implement & comment \\ + \hline\hline + {\tt FTU\_top.vhd} & {\tt FTU} & yes & yes & top level entity\\ + \hline + {\tt FTU\_top\_tb.vhd} & {\tt FTU} & yes & no & test bench\\ + \hline + {\tt ftu\_definitions.vhd} & {\tt FTU} & yes & yes & library\\ + \hline + {\tt ftu\_board.ucf} & {\tt FTU} & no & yes & pin constraints\\ + \hline + {\tt FTU\_control.vhd} & {\tt FTU} & yes & yes & top state machine\\ + \hline\hline + {\tt FTU\_clk\_gen.vhd} & {\tt FTU/clock} & yes & yes & clock interface\\ + \hline + {\tt FTU\_dcm\_50M\_to\_50M.vhd} & {\tt FTU/clock} & yes & yes & clock manager\\ + \hline\hline + {\tt FTU\_rate\_counter.vhd} & {\tt FTU/counter} & yes & yes & trigger counter\\ + \hline\hline + {\tt FTU\_spi\_interface.vhd} & {\tt FTU/dac\_spi} & yes & yes & SPI top entity\\ + \hline + {\tt FTU\_spi\_clock\_gen.vhd} & {\tt FTU/dac\_spi} & yes & yes & serial clock\\ + \hline + {\tt FTU\_distributor.vhd} & {\tt FTU/dac\_spi} & yes & yes & DAC loop\\ + \hline + {\tt FTU\_controller.vhd} & {\tt FTU/dac\_spi} & yes & yes & low level SPI\\ + \hline\hline + {\tt FTU\_dna\_gen.vhd} & {\tt FTU/dna} & yes & yes & DNA readout\\ + \hline\hline + {\tt FTU\_dual\_port\_ram64.vhd} & {\tt FTU/ram64} & yes & yes & RAM interface\\ + \hline + {\tt FTU\_dual\_port\_ram64.ngc} & {\tt FTU/ram64} & no & yes & RAM netlist\\ + \hline\hline + {\tt FTU\_rs485\_control.vhd} & {\tt FTU/rs485} & yes & yes & RS485 top entity\\ + \hline + {\tt FTU\_rs485\_interpreter.vhd} & {\tt FTU/rs485} & yes & yes & data decoding\\ + \hline + {\tt FTU\_rs485\_receiver.vhd} & {\tt FTU/rs485} & yes & yes & 28-byte buffer\\ + \hline + {\tt FTU\_rs485\_interface.vhd} & {\tt FTU/rs485} & yes & yes & low level RS485\\ + \hline + {\tt ucrc\_par.vhd} & {\tt FTU/rs485} & yes & yes & check sum\\ + \hline + \end{tabular} + \caption{List of all source files needed to compile the FTU firmware.} + \label{tab:files} +\end{table} + +\chapter{Register Tables} +\label{cha:registers} + +There are 40 accessible control and rate registers implemented in the FTU +firmware, each with a size of 8\,bit. They are organized as a 64-byte RAM (see +also section~\ref{sec:organization:design:ram}), the last 24 bytes of which +are empty and serve as spares. Table~\ref{tab:RAM} presents an overview of the +address space inside the RAM, more details can be found in +tables~\ref{tab:enables} - \ref{tab:overflow}. Registers marked as read-only +cannot be written by the FTM, but are updated by the FTU itself. + +\begin{table}[htbp] + \centering + \begin{tabular}{|c|l|l|} + \hline + RAM address & register block & comment\\ + \hline\hline + $00 \dots 07$ & enable patterns & read/write\\ + \hline + $08 \dots 27$ & rate counters & read-only\\ + \hline + $28 \dots 37$ & DAC settings & read/write\\ + \hline + $38$ & prescaling $y$ (see section~\ref{sec:organization:design:counter}) & read/write \\ + \hline + $39$ & overflow bits & read-only \\ + \hline + $40 \dots 63$ & empty & spare \\ + \hline + \end{tabular} + \caption{Overview of the register mapping inside the RAM.} + \label{tab:RAM} +\end{table} + +\section{Enable Patterns} + +\begin{table}[htbp] + \centering + %\small + \begin{tabular}{|c||l|l|l|l|l|l|l|l|} + \hline + address & bit~7 & bit~6 & bit~5 & bit~4 & bit~3 & bit~2 & bit~1 & bit~0 \\ + \hline\hline + 00 & En\_A7 & En\_A6 & En\_A5 & En\_A4 & En\_A3 & En\_A2 & En\_A1 & + En\_A0 \\ + \hline + 01 & \- & \- & \- & \- & \- & \- & \- & En\_A8 \\ + \hline + 02 & En\_B7 & En\_B6 & En\_B5 & En\_B4 & En\_B3 & En\_B2 & En\_B1 & + En\_B0 \\ + \hline + 03 & \- & \- & \- & \- & \- & \- & \- & En\_B8 \\ + \hline + 04 & En\_C7 & En\_C6 & En\_C5 & En\_C4 & En\_C3 & En\_C2 & En\_C1 & + En\_C0 \\ + \hline + 05 & \- & \- & \- & \- & \- & \- & \- & En\_C8 \\ + \hline + 06 & En\_D7 & En\_D6 & En\_D5 & En\_D4 & En\_D3 & En\_D2 & En\_D1 & + En\_D0 \\ + \hline + 07 & \- & \- & \- & \- & \- & \- & \- & En\_D8\\ + \hline + \end{tabular} + \caption{Mapping of the $4 \times 9$ enable bits inside the RAM.} + \label{tab:enables} +\end{table} + +\section{Rate Counters} + +\begin{table}[htbp] + \centering + %\small + \begin{tabular}{|c||l|l|l|l|l|l|l|l|} + \hline + address & bit~7 & bit~6 & bit~5 & bit~4 & bit~3 & bit~2 & bit~1 & bit~0 \\ + \hline\hline + 08 & Ct\_A7 & Ct\_A6 & Ct\_A5 & Ct\_A4 & Ct\_A3 & Ct\_A2 & Ct\_A1 & Ct\_A0 \\ + \hline + 09 & Ct\_A15 & Ct\_A14 & Ct\_A13 & Ct\_A12 & Ct\_A11 & Ct\_A10 & Ct\_A9 & Ct\_A8 \\ + \hline + 10 & Ct\_A23 & Ct\_A22 & Ct\_A21 & Ct\_A20 & Ct\_A19 & Ct\_A18 & Ct\_A17 & Ct\_A16 \\ + \hline + 11 & 0 & 0 & Ct\_A29 & Ct\_A28 & Ct\_A27 & Ct\_A26 & Ct\_A25 & Ct\_A24 \\ + \hline\hline + $\dots$ & $\dots$ & $\dots$ & $\dots$ & $\dots$ & $\dots$ & $\dots$ & $\dots$ & $\dots$ \\ + \hline\hline + 20 & Ct\_D7 & Ct\_D6 & Ct\_D5 & Ct\_D4 & Ct\_D3 & Ct\_D2 & Ct\_D1 & Ct\_D0 \\ + \hline + 21 & Ct\_D15 & Ct\_D14 & Ct\_D13 & Ct\_D12 & Ct\_D11 & Ct\_D10 & Ct\_D9 & Ct\_D8 \\ + \hline + 22 & Ct\_D23 & Ct\_D22 & Ct\_D21 & Ct\_D20 & Ct\_D19 & Ct\_D18 & Ct\_D17 & Ct\_D16 \\ + \hline + 23 & 0 & 0 & Ct\_D29 & Ct\_D28 & Ct\_D27 & Ct\_D26 & Ct\_D25 & Ct\_D24 \\ + \hline\hline + 24 & Ct\_T7 & Ct\_T6 & Ct\_T5 & Ct\_T4 & Ct\_T3 & Ct\_T2 & Ct\_T1 & Ct\_T0 \\ + \hline + 25 & Ct\_T15 & Ct\_T14 & Ct\_T13 & Ct\_T12 & Ct\_T11 & Ct\_T10 & Ct\_T9 & Ct\_T8 \\ + \hline + 26 & Ct\_T23 & Ct\_T22 & Ct\_T21 & Ct\_T20 & Ct\_T19 & Ct\_T18 & Ct\_T17 & Ct\_T16 \\ + \hline + 27 & 0 & 0 & Ct\_T29 & Ct\_T28 & Ct\_T27 & Ct\_T26 & Ct\_T25 & Ct\_T24 \\ + \hline + \end{tabular} + \caption{Mapping of the four patch counter (A--D) and the trigger counter + reading (T) inside the RAM. The two most significant bits of the 32 bits per counter are always + set to 0.} + \label{tab:rates} +\end{table} + +\section{DAC Settings} + +\begin{table}[htbp] + \centering + \begin{tabular}{|c|l|} + \hline + address & data[$7 \dots 0$]\\ + \hline\hline + 28 & DAC\_A\_[$7 \dots 0$] \\ + \hline + 29 & DAC\_A\_[$15 \dots 8$] \\ + \hline + $\dots$ & $\dots$\\ + \hline + 34 & DAC\_D\_[$7 \dots 0$] \\ + \hline + 35 & DAC\_D\_[$15 \dots 8$] \\ + \hline + 36 & DAC\_H\_[$7 \dots 0$] \\ + \hline + 37 & DAC\_H\_[$15 \dots 8$] \\ + \hline + \end{tabular} + \caption{Mapping of the DAC values (12\,bit) for the thresholds (DAC\_A -- DAC\_D) and the + $n$-out-of-4 logic (DAC\_H) inside the RAM; the bits $15\dots 12$ are filled up with zeros.} + \label{tab:dacs} +\end{table} + +\section{Overflow Bits} + +\begin{table}[htbp] + \centering + \begin{tabular}{|l|c|c|c|c|c|c|} + \hline + bit & $7 \dots 5$ & 4 & 3 & 2 & 1 & 0 \\ + \hline\hline + content & not used & overflow\_T & overflow\_D & overflow\_C & overflow\_B & overflow\_A \\ + \hline + \end{tabular} + \caption{Bit mapping inside the RAM overflow register (address 39).} + \label{tab:overflow} +\end{table} + +\chapter{Communication with FTM} +\label{cha:communication} + +The slow control system between the FTU boards (slaves) and the FTM (master) +is based on two transmission sequences: Either the FTM is sending data to a +particular FTU, or a particular FTU is answering to the FTM. Broadcast +commands are not supported. Each board has a unique 1-byte address for +identification on the RS485 buses, which is 0--63 for the FTUs\footnote{Two + bits are used to specify the crate, four bits to indicate the slot position + within a crate. This 6-bit address is different from the 57-bit DNA which is + FPGA-bound (see section~\ref{sec:organization:design:dna}).} and 192 for the +FTM. The transmission sequences are of fixed length (28\,byte) and, if +necessary, filled up with arbitrary data. In case the data transmission is +disturbed or not complete, a time-out system ensures that the communication +doesn't get stuck\footnote{At a baud rate of 250\,kHz, for example, this + time-out is set to 2\,ms on the FTU side.}. In the following, the slow +control protocol, the instruction codes and the check sum error-detection are +discussed. + +\section{Transmission Protocol} + +Table~\ref{tab:protocol} summarizes the structure of the data sequences sent +between the FTM and the FTUs. A FTU only replies if contacted by the FTM. The +answer is a copy of the received data package with swapped source/destination +address and eventually the requested data. Byte 26 is used to transmit the +number of CRC errors counted by a FTU until a valid sequence arrived. In that +case the number of errors is communicated and the error counter is set to 0. + +\begin{table}[htbp] + \centering + \begin{tabular}{|c|l|l|}\hline + byte & content & comment \\ + \hline\hline + $00$ & start delimiter & ASCI @ (binary "01000000")\\ + \hline + $01$ & destination address & 192 (FTM) or slot position 0--63 (FTUs)\\ + \hline + $02$ & source address & 192 (FTM) or slot position 0--63 (FTUs)\\ + \hline + $03$ & firmware ID & firmware version of source FPGA\\ + \hline + $04$ & instruction / info & see section~\ref{cha:communication:instr}\\ + \hline + $05 \dots 25$ & 21 byte data & DACs, rates, etc.\\ + \hline + $26$ & CRC error counter & number of CRC errors on FTU \\ + \hline + $27$ & check sum & CRC-8-CCITT, see section~\ref{cha:communication:crc}\\ + \hline + \end{tabular} + \caption{Composition of the FTM-FTU slow control data packages.} + \label{tab:protocol} +\end{table} + +\section{Instruction Table} +\label{cha:communication:instr} + +A set of eight instructions has been foreseen for the communication between +the FTM and the FTUs. They are listed in table~\ref{tab:instructions} +including a short description. In case a FTU receives the ping-pong command, +it returns also the DNA of its FPGA (see +section~\ref{sec:organization:design:dna}). Combined with the 6-bit address, +which is related to the geographical position insided the camera crates, it is +therefore possible to identify each FTU. + +\begin{table}[htbp] + \centering + \begin{tabular}{|c|l|l|} + \hline + code & instruction & description \\ + \hline\hline + 00 & set DAC & write new values into DAC registers \\ + \hline + 01 & read DAC & read back content of DAC registers \\ + \hline + 02 & read rates & read out rates and overflow bits \\ + \hline + 03 & set enable & write new patterns into enable registers \\ + \hline + 04 & read enable & read back content of enable registers \\ + \hline + 05 & ping-pong & ping a FTU to check communication (see text)\\ + \hline + 06 & set counter mode & write into the prescaling register \\ + \hline + 07 & read counter mode & read back prescaling and overflow registers \\ + \hline + \end{tabular} + \caption{Instruction set for the FTM-FTU slow control communication.} + \label{tab:instructions} +\end{table} + +\section{CRC Calculation} +\label{cha:communication:crc} + +The integrity of the 28-byte data packages is evaluated by means of a Cyclic +Redundancy Check (CRC). The 8-CCITT CRC has been chosen which is based on the +polynomial $x^8 + x^2 + x + 1$ (00000111, omitting the most significant +bit). Bytes 0--26 of table~\ref{tab:protocol} constitute the input vector for +the CRC calculation, the resulting 1-byte check sum being compared with the +one transmitted by the FTM (byte 27 in table~\ref{tab:protocol}). If the check +sum turns out to be wrong, the FTU doesn't answer and increases the number of +error counts. The FTM will consequently run into a time-out and repeat its +command. After a valid sequence has finally arrived, the FTU will include in +its answer the number of CRC errors counted (byte 26 in +table~\ref{tab:protocol}) and reset the error counter. + +\chapter{Finite State Machines} +\label{cha:fsm} + +There are several finite state machines (FSM) used in the FTU firmware design, +distributed over several files. They are in principal all running in parallel, +some of them are, however, only waking up if triggered by the main +control. This is for example the case for the SPI interface controlling the +DAC settings. Since the most complicated FSMs are inside {\tt FTU\_control} +and {\tt FTU\_rs485\_control} (see section~\ref{sec:organization:design}), +they are explained in more detail in this chapter. + +\section{Main Control FSM} + +This state machine has full control over the FTU board during operation. After +power-up or reboot it is in an {\tt IDLE} state, waiting for the DCMs to +lock. Afterwards it passes through two {\tt INIT} sequences, where default +values for all registers are written to the RAM and the DNA is read out. The +defaults are all defined in the library {\tt ftu\_definitions}. When the +initialization has finished, the {\tt RUNNING} state is entered. This is the +principal state during which the board is counting triggers. {\tt RUNNING} is +left only if a counting period has finished and the number of counts is stored +in the RAM, or if a command has arrived via RS485 and is communicated by the +responsible FSM (see next section). A dedicated state has been implemented for +each possible command and, if appropriate, also for the subsequent change of +settings (e.g. {\tt CONFIG\_DAC}). In any case the board goes back to {\tt + RUNNING}. + +\section{RS485 Control FSM} + +The main and default state of this FSM is {\tt RECEIVE}. This means that the +RS485 receiver is enabled and the board is waiting for commands from the +FTM. If a full 28-byte package has arrived and correctly been +decoded\footnote{This involves a further state machine which is inside the + file {\tt FTU\_rs485\_interpreter.vhd}}, the main control FSM is informed +about the instruction (e.g. new DACs). The RS485 FSM then enters a wait state +(e.g. {\tt SET\_DAC\_WAIT}) until it gets an internal ready signal. It +subsequently sends the answer to the FTM (e.g. {\tt SET\_DAC\_TRANSMIT}) and +goes back to {\tt RECEIVE}. While during {\tt RECEIVE} the RS485 FSM and all +processes below are running in parallel to the main control FSM, the sequence +of states in case a command has arrived is prescribed. + +\end{document} Index: firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new.vhd =================================================================== --- firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new.vhd (revision 10057) +++ firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new.vhd (revision 10057) @@ -0,0 +1,255 @@ +---------------------------------------------------------------------------------- +-- Company: ETH Zurich, Institute for Particle Physics +-- Engineer: P. Vogler, Q. Weitzel +-- +-- Create Date: 11/19/2010 +-- Design Name: +-- Module Name: FTU_test6_new - Behavioral +-- Project Name: +-- Target Devices: +-- Tool versions: +-- Description: Test firmware for FTU board, set enables via RS485, new version +-- +-- Dependencies: +-- +-- Revision: +-- Revision 0.01 - File Created +-- Additional Comments: +-- +---------------------------------------------------------------------------------- +library IEEE; +use IEEE.STD_LOGIC_1164.ALL; +use IEEE.STD_LOGIC_ARITH.ALL; +use IEEE.STD_LOGIC_UNSIGNED.ALL; +library ftu_definitions_test6_new; +USE ftu_definitions_test6_new.ftu_array_types.all; + +---- Uncomment the following library declaration if instantiating +---- any Xilinx primitives in this code. +--library UNISIM; +--use UNISIM.VComponents.all; + +entity FTU_test6_new is + port( + -- global control + ext_clk : IN STD_LOGIC; -- external clock from FTU board + --brd_add : IN STD_LOGIC_VECTOR(5 downto 0); -- geographic board/slot address + --brd_id : in STD_LOGIC_VECTOR(7 downto 0); -- local solder-programmable board ID + + -- rate counters LVDS inputs + -- use IBUFDS differential input buffer + --patch_A_p : IN STD_LOGIC; -- logic signal from first trigger patch + --patch_A_n : IN STD_LOGIC; + --patch_B_p : IN STD_LOGIC; -- logic signal from second trigger patch + --patch_B_n : IN STD_LOGIC; + --patch_C_p : IN STD_LOGIC; -- logic signal from third trigger patch + --patch_C_n : IN STD_LOGIC; + --patch_D_p : IN STD_LOGIC; -- logic signal from fourth trigger patch + --patch_D_n : IN STD_LOGIC; + --trig_prim_p : IN STD_LOGIC; -- logic signal from n-out-of-4 circuit + --trig_prim_n : IN STD_LOGIC; + + -- DAC interface + --sck : OUT STD_LOGIC; -- serial clock to DAC + --mosi : OUT STD_LOGIC; -- serial data to DAC, master-out-slave-in + --clr : OUT STD_LOGIC; -- clear signal to DAC + --cs_ld : OUT STD_LOGIC; -- chip select or load to DAC + + -- RS-485 interface to FTM + rx : IN STD_LOGIC; -- serial data from FTM + tx : OUT STD_LOGIC; -- serial data to FTM + rx_en : OUT STD_LOGIC; -- enable RS-485 receiver + tx_en : OUT STD_LOGIC; -- enable RS-485 transmitter + + -- analog buffer enable + enables_A : OUT STD_LOGIC_VECTOR(8 downto 0); -- individual enables for analog inputs + enables_B : OUT STD_LOGIC_VECTOR(8 downto 0); -- individual enables for analog inputs + enables_C : OUT STD_LOGIC_VECTOR(8 downto 0); -- individual enables for analog inputs + enables_D : OUT STD_LOGIC_VECTOR(8 downto 0) -- individual enables for analog inputs + + -- testpoints + --TP_A : out STD_LOGIC_VECTOR(11 downto 0) -- testpoints + ); +end FTU_test6_new; + + +architecture Behavioral of FTU_test6_new is + + component FTU_test6_new_dcm + port( + CLKIN_IN : IN STD_LOGIC; + RST_IN : IN STD_LOGIC; + CLKFX_OUT : OUT STD_LOGIC; + CLKIN_IBUFG_OUT : OUT STD_LOGIC; + LOCKED_OUT : OUT STD_LOGIC + ); + end component; + + component FTU_test6_new_rs485_interface + GENERIC( + CLOCK_FREQUENCY : integer := 50000000; -- Hertz + BAUD_RATE : integer := 250000 -- bits / sec + ); + PORT( + clk : IN std_logic; + -- RS485 + rx_d : IN std_logic; + rx_en : OUT std_logic; + tx_d : OUT std_logic; + tx_en : OUT std_logic; + -- FPGA + rx_data : OUT std_logic_vector(7 DOWNTO 0); + --rx_busy : OUT std_logic := '0'; + rx_valid : OUT std_logic := '0'; + tx_data : IN std_logic_vector(7 DOWNTO 0); + tx_busy : OUT std_logic := '0'; + tx_start : IN std_logic + ); + end component; + + signal reset_sig : STD_LOGIC := '0'; -- initialize reset to 0 at power up + signal clk_50M_sig : STD_LOGIC; + + signal enable_sig : enable_array_type := DEFAULT_ENABLE; + + signal rx_en_sig : STD_LOGIC := '0'; + signal tx_en_sig : STD_LOGIC := '0'; + signal rx_sig : STD_LOGIC; + signal tx_sig : STD_LOGIC := 'X'; + signal rx_data_sig : STD_LOGIC_VECTOR(7 DOWNTO 0) := (others => '0'); + signal rx_busy_sig : STD_LOGIC; + signal rx_valid_sig : STD_LOGIC; + + type FTU_test6_new_StateType is (INIT, RUN1, RUN2, RUN3, RUN4); + signal FTU_test6_new_State, FTU_test6_new_NextState: FTU_test6_new_StateType; + +begin + + Inst_FTU_test6_new_dcm : FTU_test6_new_dcm + port map( + CLKIN_IN => ext_clk, + RST_IN => reset_sig, + CLKFX_OUT => clk_50M_sig, + CLKIN_IBUFG_OUT => open, + LOCKED_OUT => open + ); + + Inst_FTU_test6_new_rs485_interface : FTU_test6_new_rs485_interface + generic map( + CLOCK_FREQUENCY => 50000000, + --BAUD_RATE => 10000000 --simulation + BAUD_RATE => 250000 --implement + ) + port map( + clk => clk_50M_sig, + -- RS485 + rx_d => rx_sig, + rx_en => rx_en_sig, + tx_d => tx_sig, + tx_en => tx_en_sig, + -- FPGA + rx_data => rx_data_sig, + --rx_busy => rx_busy_sig, + rx_valid => rx_valid_sig, + tx_data => (others => '0'), + tx_busy => open, + tx_start => '0' + ); + + enables_A <= enable_sig(0)(8 downto 0); + enables_B <= enable_sig(1)(8 downto 0); + enables_C <= enable_sig(2)(8 downto 0); + enables_D <= enable_sig(3)(8 downto 0); + + rx_en <= rx_en_sig; + tx_en <= tx_en_sig; + tx <= tx_sig; + rx_sig <= rx; + + --FTU main state machine (two-process implementation) + + FTU_test6_new_Registers: process (clk_50M_sig) + begin + if Rising_edge(clk_50M_sig) then + FTU_test6_new_State <= FTU_test6_new_NextState; + end if; + end process FTU_test6_new_Registers; + + FTU_test6_new_C_logic: process (FTU_test6_new_State, rx_data_sig, rx_valid_sig) + begin + FTU_test6_new_NextState <= FTU_test6_new_State; + case FTU_test6_new_State is + when INIT => + reset_sig <= '0'; + enable_sig <= DEFAULT_ENABLE; + if (rx_data_sig = "00110001" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN1; + elsif (rx_data_sig = "00110010" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN2; + elsif (rx_data_sig = "00110011" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN3; + elsif (rx_data_sig = "00110100" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN4; + else + FTU_test6_new_NextState <= INIT; + end if; + when RUN1 => + reset_sig <= '0'; + enable_sig <= ("0000000000000000","0000000111111111","0000000111111111","0000000111111111"); + if (rx_data_sig = "00110000" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= INIT; + elsif (rx_data_sig = "00110010" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN2; + elsif (rx_data_sig = "00110011" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN3; + elsif (rx_data_sig = "00110100" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN4; + else + FTU_test6_new_NextState <= RUN1; + end if; + when RUN2 => + reset_sig <= '0'; + enable_sig <= ("0000000111111111","0000000000000000","0000000111111111","0000000111111111"); + if (rx_data_sig = "00110000" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= INIT; + elsif (rx_data_sig = "00110001" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN1; + elsif (rx_data_sig = "00110011" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN3; + elsif (rx_data_sig = "00110100" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN4; + else + FTU_test6_new_NextState <= RUN2; + end if; + when RUN3 => + reset_sig <= '0'; + enable_sig <= ("0000000111111111","0000000111111111","0000000000000000","0000000111111111"); + if (rx_data_sig = "00110000" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= INIT; + elsif (rx_data_sig = "00110001" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN1; + elsif (rx_data_sig = "00110010" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN2; + elsif (rx_data_sig = "00110100" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN4; + else + FTU_test6_new_NextState <= RUN3; + end if; + when RUN4 => + reset_sig <= '0'; + enable_sig <= ("0000000111111111","0000000111111111","0000000111111111","0000000000000000"); + if (rx_data_sig = "00110000" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= INIT; + elsif (rx_data_sig = "00110001" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN1; + elsif (rx_data_sig = "00110010" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN2; + elsif (rx_data_sig = "00110011" and rx_valid_sig = '1') then + FTU_test6_new_NextState <= RUN3; + else + FTU_test6_new_NextState <= RUN4; + end if; + end case; + end process FTU_test6_new_C_logic; + +end Behavioral; Index: firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new_dcm.vhd =================================================================== --- firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new_dcm.vhd (revision 10057) +++ firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new_dcm.vhd (revision 10057) @@ -0,0 +1,90 @@ +-------------------------------------------------------------------------------- +-- Copyright (c) 1995-2009 Xilinx, Inc. All rights reserved. +-------------------------------------------------------------------------------- +-- ____ ____ +-- / /\/ / +-- /___/ \ / Vendor: Xilinx +-- \ \ \/ Version : 11.1 +-- \ \ Application : xaw2vhdl +-- / / Filename : FTU_dac_dcm.vhd +-- /___/ /\ Timestamp : 01/20/2010 16:36:17 +-- \ \ / \ +-- \___\/\___\ +-- +--Command: xaw2vhdl-st /home/qweitzel/FPGA/FACT/FTU/source/ip_cores/FTU_dac_dcm.xaw /home/qweitzel/FPGA/FACT/FTU/source/ip_cores/FTU_dac_dcm +--Design Name: FTU_dac_dcm +--Device: xc3s400an-4fgg400 +-- +-- Module FTU_dac_dcm +-- Generated by Xilinx Architecture Wizard +-- Written for synthesis tool: XST +-- Period Jitter (unit interval) for block DCM_SP_INST = 0.03 UI +-- Period Jitter (Peak-to-Peak) for block DCM_SP_INST = 6.54 ns + +library ieee; +use ieee.std_logic_1164.ALL; +use ieee.numeric_std.ALL; +library UNISIM; +use UNISIM.Vcomponents.ALL; + +entity FTU_test6_new_dcm is + port ( CLKIN_IN : in std_logic; + RST_IN : in std_logic; + CLKFX_OUT : out std_logic; + CLKIN_IBUFG_OUT : out std_logic; + LOCKED_OUT : out std_logic); +end FTU_test6_new_dcm; + +architecture BEHAVIORAL of FTU_test6_new_dcm is + signal CLKFX_BUF : std_logic; + signal CLKIN_IBUFG : std_logic; + signal GND_BIT : std_logic; +begin + GND_BIT <= '0'; + CLKIN_IBUFG_OUT <= CLKIN_IBUFG; + CLKFX_BUFG_INST : BUFG + port map (I=>CLKFX_BUF, + O=>CLKFX_OUT); + + CLKIN_IBUFG_INST : IBUFG + port map (I=>CLKIN_IN, + O=>CLKIN_IBUFG); + + DCM_SP_INST : DCM_SP + generic map( CLK_FEEDBACK => "NONE", + CLKDV_DIVIDE => 2.0, + CLKFX_DIVIDE => 2, + CLKFX_MULTIPLY => 2, + CLKIN_DIVIDE_BY_2 => FALSE, + CLKIN_PERIOD => 20.000, + CLKOUT_PHASE_SHIFT => "NONE", + DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS", + DFS_FREQUENCY_MODE => "LOW", + DLL_FREQUENCY_MODE => "LOW", + DUTY_CYCLE_CORRECTION => TRUE, + FACTORY_JF => x"C080", + PHASE_SHIFT => 0, + STARTUP_WAIT => FALSE) + port map (CLKFB=>GND_BIT, + CLKIN=>CLKIN_IBUFG, + DSSEN=>GND_BIT, + PSCLK=>GND_BIT, + PSEN=>GND_BIT, + PSINCDEC=>GND_BIT, + RST=>RST_IN, + CLKDV=>open, + CLKFX=>CLKFX_BUF, + CLKFX180=>open, + CLK0=>open, + CLK2X=>open, + CLK2X180=>open, + CLK90=>open, + CLK180=>open, + CLK270=>open, + LOCKED=>LOCKED_OUT, + PSDONE=>open, + STATUS=>open); + +end BEHAVIORAL; + + Index: firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new_rs485_interface.vhd =================================================================== --- firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new_rs485_interface.vhd (revision 10057) +++ firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new_rs485_interface.vhd (revision 10057) @@ -0,0 +1,126 @@ +-- +-- VHDL Architecture FACT_FAD_lib.rs485_interface.beha +-- +-- Created: +-- by - Benjamin Krumm.UNKNOWN (EEPC8) +-- at - 13:24:23 08.06.2010 +-- +-- using Mentor Graphics HDL Designer(TM) 2009.1 (Build 12) +-- +-- +-- modified for FTU design by Q. Weitzel, 30 July 2010 +-- + +LIBRARY ieee; +USE ieee.std_logic_1164.all; +USE ieee.std_logic_arith.all; + +-- library ftu_definitions; +-- USE ftu_definitions.ftu_array_types.all; +-- USE ftu_definitions.ftu_constants.all; + +ENTITY FTU_test6_new_rs485_interface IS + GENERIC( + CLOCK_FREQUENCY : integer := 50000000; + BAUD_RATE : integer := 250000 + ); + PORT( + clk : IN std_logic; + -- RS485 + rx_d : IN std_logic; + rx_en : OUT std_logic; + tx_d : OUT std_logic; + tx_en : OUT std_logic; + -- FPGA + rx_data : OUT std_logic_vector (7 DOWNTO 0); + --rx_busy : OUT std_logic := '0'; + rx_valid : OUT std_logic := '0'; + tx_data : IN std_logic_vector (7 DOWNTO 0); + tx_busy : OUT std_logic := '0'; + tx_start : IN std_logic + ); + +END FTU_test6_new_rs485_interface; + +ARCHITECTURE beha OF FTU_test6_new_rs485_interface IS + + signal flow_ctrl : std_logic := '0'; -- '0' -> RX enable, '1' -> TX enable + + --transmit + signal tx_start_f : std_logic := '0'; + signal tx_sr : std_logic_vector(10 downto 0) := (others => '1'); -- start bit, 8 data bits, 2 stop bits + signal tx_bitcnt : integer range 0 to 11 := 11; + signal tx_cnt : integer range 0 to ((CLOCK_FREQUENCY / BAUD_RATE) - 1); + + --receive + signal rx_dsr : std_logic_vector(3 downto 0) := (others => '1'); + signal rx_sr : std_logic_vector(7 downto 0) := (others => '0'); + signal rx_bitcnt : integer range 0 to 11 := 11; + signal rx_cnt : integer range 0 to ((CLOCK_FREQUENCY / BAUD_RATE) - 1); + +BEGIN + + -- Senden + tx_data_proc: process(clk) + begin + if rising_edge(clk) then + tx_start_f <= tx_start; + if (tx_start = '1' or tx_bitcnt < 11) then + flow_ctrl <= '1'; + else + flow_ctrl <= '0'; + end if; + if (tx_start = '1' and tx_start_f = '0') then -- steigende Flanke, los gehts + tx_cnt <= 0; -- Zaehler initialisieren + tx_bitcnt <= 0; + tx_sr <= "11" & tx_data & '0'; -- 2 x Stopbit, 8 Datenbits, Startbit, rechts gehts los + else + if (tx_cnt < (CLOCK_FREQUENCY/BAUD_RATE) - 1) then + tx_cnt <= tx_cnt + 1; + else -- naechstes Bit ausgeben + if (tx_bitcnt < 11) then + tx_cnt <= 0; + tx_bitcnt <= tx_bitcnt + 1; + tx_sr <= '1' & tx_sr(tx_sr'left downto 1); + end if; + end if; + end if; + end if; + end process; + + tx_en <= flow_ctrl; + tx_d <= tx_sr(0); -- LSB first + tx_busy <= '1' when (tx_start = '1' or tx_bitcnt < 11) else '0'; + + -- Empfangen + rx_data_proc: process(clk) + begin + if rising_edge(clk) then + rx_dsr <= rx_dsr(rx_dsr'left - 1 downto 0) & rx_d; + if (rx_bitcnt < 11) then -- Empfang laeuft + if (rx_cnt < (CLOCK_FREQUENCY/BAUD_RATE) - 1) then + rx_cnt <= rx_cnt + 1; + else + rx_cnt <= 0; + rx_bitcnt <= rx_bitcnt + 1; + if (rx_bitcnt < 9) then + rx_sr <= rx_dsr(rx_dsr'left - 1) & rx_sr(rx_sr'left downto 1); -- rechts schieben, weil LSB first + else + rx_valid <= '1'; + end if; + end if; + else + if (rx_dsr(3 downto 2) = "10") then -- warten auf Start bit + rx_valid <= '0'; + rx_cnt <= ((CLOCK_FREQUENCY / BAUD_RATE) - 1) / 2; + rx_bitcnt <= 0; + end if; + end if; + end if; + end process; + + rx_en <= flow_ctrl; + rx_data <= rx_sr; + --rx_busy <= '1' when (rx_bitcnt < 11) else '0'; + +END ARCHITECTURE beha; Index: firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new_tb.vhd =================================================================== --- firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new_tb.vhd (revision 10057) +++ firmware/FTU/test_firmware/FTU_test6_new/FTU_test6_new_tb.vhd (revision 10057) @@ -0,0 +1,162 @@ +-------------------------------------------------------------------------------- +-- Company: ETH Zurich, Institute for Particle Physics +-- Engineer: Q. Weitzel, P. Vogler +-- +-- Create Date: 19.11.2010 +-- Design Name: +-- Module Name: FTU_test6_new_tb.vhd +-- Project Name: +-- Target Device: +-- Tool versions: +-- Description: Testbench for FTU RS485 test +-- +-- VHDL Test Bench Created by ISE for module: FTU_test6_new +-- +-- Dependencies: +-- +-- Revision: +-- Revision 0.01 - File Created +-- Additional Comments: +-- +-- Notes: +-- This testbench has been automatically generated using types std_logic and +-- std_logic_vector for the ports of the unit under test. Xilinx recommends +-- that these types always be used for the top-level I/O of a design in order +-- to guarantee that the testbench will bind correctly to the post-implementation +-- simulation model. +-------------------------------------------------------------------------------- +library IEEE; +use IEEE.STD_LOGIC_1164.ALL; +use IEEE.STD_LOGIC_UNSIGNED.ALL; +use IEEE.NUMERIC_STD.ALL; + +library UNISIM; +use UNISIM.VComponents.all; + +entity FTU_test6_new_tb is +end FTU_test6_new_tb; + +architecture behavior of FTU_test6_new_tb is + + -- Component Declaration for the Unit Under Test (UUT) + + component FTU_test6_new + port( + ext_clk : IN STD_LOGIC; + rx : IN STD_LOGIC; + tx : OUT STD_LOGIC; + rx_en : OUT STD_LOGIC; + tx_en : OUT STD_LOGIC; + enables_A : OUT STD_LOGIC_VECTOR(8 downto 0); + enables_B : OUT STD_LOGIC_VECTOR(8 downto 0); + enables_C : OUT STD_LOGIC_VECTOR(8 downto 0); + enables_D : OUT STD_LOGIC_VECTOR(8 downto 0) + ); + end component; + + --Inputs + signal clk : STD_LOGIC := '0'; + signal rx : STD_LOGIC := '1'; + + --Outputs + signal enables_A : STD_LOGIC_VECTOR(8 downto 0); + signal enables_B : STD_LOGIC_VECTOR(8 downto 0); + signal enables_C : STD_LOGIC_VECTOR(8 downto 0); + signal enables_D : STD_LOGIC_VECTOR(8 downto 0); + signal tx : STD_LOGIC; + signal rx_en : STD_LOGIC; + signal tx_en : STD_LOGIC; + + -- Clock period definitions + constant clk_period : TIME := 20 ns; + constant baud_rate_period : TIME := 4 us; + +begin + + -- Instantiate the Unit Under Test (UUT) + uut: FTU_test6_new + port map( + ext_clk => clk, + rx => rx, + tx => tx, + rx_en => rx_en, + tx_en => tx_en, + enables_A => enables_A, + enables_B => enables_B, + enables_C => enables_C, + enables_D => enables_D + ); + + -- Stimulus process for clock + clk_proc: process + begin + clk <= '0'; + wait for clk_period/2; + clk <= '1'; + wait for clk_period/2; + end process clk_proc; + + -- Stimulus process for RS485 + rs485_proc: process + + procedure assign_rs485 (data: std_logic_vector(7 downto 0)) is + begin + rx <= '0'; --start bit + wait for baud_rate_period; + rx <= data(0); --bit 0 + wait for baud_rate_period; + rx <= data(1); --bit 1 + wait for baud_rate_period; + rx <= data(2); --bit 2 + wait for baud_rate_period; + rx <= data(3); --bit 3 + wait for baud_rate_period; + rx <= data(4); --bit 4 + wait for baud_rate_period; + rx <= data(5); --bit 5 + wait for baud_rate_period; + rx <= data(6); --bit 6 + wait for baud_rate_period; + rx <= data(7); --bit 7 + wait for baud_rate_period; + rx <= '1'; --stop bit + wait for baud_rate_period; + rx <= '1'; --stop bit + wait for baud_rate_period; + end assign_rs485; + + begin + wait for 1us; + --------------------------------------------------------------------------- + -- send a '1' character + --------------------------------------------------------------------------- + assign_rs485("00110001"); + wait for 1us; + --------------------------------------------------------------------------- + -- send a '2' character + --------------------------------------------------------------------------- + assign_rs485("00110010"); + wait for 1us; + --------------------------------------------------------------------------- + -- send a '3' character + --------------------------------------------------------------------------- + assign_rs485("00110011"); + wait for 1us; + --------------------------------------------------------------------------- + -- send a '4' character + --------------------------------------------------------------------------- + assign_rs485("00110100"); + wait for 1us; + --------------------------------------------------------------------------- + -- send a '0' character + --------------------------------------------------------------------------- + assign_rs485("00110000"); + wait for 1us; + --------------------------------------------------------------------------- + -- don't forget final wait! + --------------------------------------------------------------------------- + wait; + + end process rs485_proc; + +end; Index: firmware/FTU/test_firmware/FTU_test6_new/ftu_board_test6_new.ucf =================================================================== --- firmware/FTU/test_firmware/FTU_test6_new/ftu_board_test6_new.ucf (revision 10057) +++ firmware/FTU/test_firmware/FTU_test6_new/ftu_board_test6_new.ucf (revision 10057) @@ -0,0 +1,145 @@ +######################################################## +# FTU Board +# FACT Trigger Unit +# +# Pin location constraints +# +# by Patrick Vogler, Quirin Weitzel +# 30 July 2010 (for FTU_test6_new) +######################################################## + + +#Clock +####################################################### +NET ext_clk LOC = Y11 | IOSTANDARD=LVCMOS33; # Clk + + +# RS-485 Interface +####################################################### +NET rx_en LOC = T20 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # 485_RE: enable RS-485 receiver +NET tx_en LOC = U20 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # 485_DE: enable RS-485 transmitter +NET tx LOC = U19 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # 485_DO: serial data to FTM +NET rx LOC = R20 | IOSTANDARD=LVCMOS33; # 485_DI: serial data from FTM + + +# Board ID - inputs +# local board-ID "solder programmable" +####################################################### +#NET brd_id<0> LOC = C4 | IOSTANDARD=LVCMOS33; # P0 +#NET brd_id<1> LOC = C5 | IOSTANDARD=LVCMOS33; # P1 +#NET brd_id<2> LOC = C6 | IOSTANDARD=LVCMOS33; # P2 +#NET brd_id<3> LOC = C7 | IOSTANDARD=LVCMOS33; # P3 +#NET brd_id<4> LOC = C8 | IOSTANDARD=LVCMOS33; # P4 +#NET brd_id<5> LOC = B8 | IOSTANDARD=LVCMOS33; # P5 +#NET brd_id<6> LOC = C9 | IOSTANDARD=LVCMOS33; # P6 +#NET brd_id<7> LOC = B9 | IOSTANDARD=LVCMOS33; # P7 + + +# Board Addresses +# geographical slot address +####################################################### +#NET brd_add<0> LOC = A15 | IOSTANDARD=LVCMOS33; # ADDR0 +#NET brd_add<1> LOC = B15 | IOSTANDARD=LVCMOS33; # ADDR1 +#NET brd_add<2> LOC = A16 | IOSTANDARD=LVCMOS33; # ADDR2 +#NET brd_add<3> LOC = A17 | IOSTANDARD=LVCMOS33; # ADDR3 +#NET brd_add<4> LOC = A18 | IOSTANDARD=LVCMOS33; # ADDR4 +#NET brd_add<5> LOC = B18 | IOSTANDARD=LVCMOS33; # ADDR5 + + +# DAC SPI Interface +####################################################### +#NET mosi LOC = E20 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #MOSI: serial data to DAC, master-out-slave-in +#NET sck LOC = E19 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #SCK: serial clock to DAC +#NET cs_ld LOC = E18 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #DAC_CS: chip select or load to DAC +#NET clr LOC = D20 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #DAC_CRL: clear signal to DAC + + +# Testpoints +###################################################### +# on Connector J5 +#NET TP_A<0> LOC = B3 | IOSTANDARD=LVCMOS33; # TP0_0 +#NET TP_A<1> LOC = A3 | IOSTANDARD=LVCMOS33; # TP1_0 +#NET TP_A<2> LOC = A4 | IOSTANDARD=LVCMOS33; # TP2_0 +#NET TP_A<3> LOC = B5 | IOSTANDARD=LVCMOS33; # TP2_0 + +# on Connector J6 +#NET TP_A<4> LOC = A5 | IOSTANDARD=LVCMOS33; # TP4_0 +#NET TP_A<5> LOC = A6 | IOSTANDARD=LVCMOS33; # TP5_0 +#NET TP_A<6> LOC = B7 | IOSTANDARD=LVCMOS33; # TP6_0 +#NET TP_A<7> LOC = A7 | IOSTANDARD=LVCMOS33; # TP7_0 + +# on Connector J7 +#NET TP_A<8> LOC = B11 | IOSTANDARD=LVCMOS33; # TP8_0 +#NET TP_A<9> LOC = A12 | IOSTANDARD=LVCMOS33; # TP9_0 +#NET TP_A<10> LOC = B12 | IOSTANDARD=LVCMOS33; # TP10_0 +#NET TP_A<11> LOC = A14 | IOSTANDARD=LVCMOS33; # TP11_0 + + +# Rate counter LVDS Inputs +###################################################### +# logic signal from first trigger patch +#NET patch_A_p LOC = Y4 | IOSTANDARD=LVDS_33 | DIFF_TERM=No; # LVDS0_P +#NET patch_A_n LOC = Y5 | IOSTANDARD=LVDS_33 | DIFF_TERM=No; # LVDS0_N + +# logic signal from second trigger patch +#NET patch_B_p LOC = Y6 | IOSTANDARD=LVDS_33 | DIFF_TERM=No; # LVDS1_P +#NET patch_B_n LOC = Y7 | IOSTANDARD=LVDS_33 | DIFF_TERM=No; # LVDS1_N + +# logic signal from third trigger patch +#NET patch_C_p LOC = Y17 | IOSTANDARD=LVDS_33 | DIFF_TERM=No ; # LVDS2_P +#NET patch_C_n LOC = Y18 | IOSTANDARD=LVDS_33 | DIFF_TERM=No ; # LVDS2_N + +# logic signal from fourth trigger patch +#NET patch_D_p LOC = Y16 | IOSTANDARD=LVDS_33 | DIFF_TERM=No ; # LVDS3_P +#NET patch_D_n LOC = W16 | IOSTANDARD=LVDS_33 | DIFF_TERM=No ; # LVDS3_N + +#The Trigger Primitive: logic signal from n-out-of-4 circuit +#NET trig_prim_p LOC = Y13 | IOSTANDARD=LVDS_33 | DIFF_TERM=No ; # TRG_P+ +#NET trig_prim_n LOC = W13 | IOSTANDARD=LVDS_33 | DIFF_TERM=No ; # TRG_P- + + +# Enables +###################################################### +# Patch 0 +NET enables_A<0> LOC = D2 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # XEN0_0 +NET enables_A<1> LOC = B1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # XEN0_1 +NET enables_A<2> LOC = C2 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # XEN0_2 +NET enables_A<3> LOC = D1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # XEN0_3 +NET enables_A<4> LOC = C1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # XEN0_4 +NET enables_A<5> LOC = D4 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # XEN0_5 +NET enables_A<6> LOC = E1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # XEN0_6 +NET enables_A<7> LOC = D3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # XEN0_7 +NET enables_A<8> LOC = E3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; # XEN0_8 + +## Patch 1 +NET enables_B<0> LOC = F2 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN1_0 +NET enables_B<1> LOC = F4 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN1_1 +NET enables_B<2> LOC = F3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN1_2 +NET enables_B<3> LOC = F1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN1_3 +NET enables_B<4> LOC = G3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN1_4 +NET enables_B<5> LOC = G4 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN1_5 +NET enables_B<6> LOC = H2 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN1_6 +NET enables_B<7> LOC = H3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN1_7 +NET enables_B<8> LOC = J3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN1_8 + +# Patch 2 +NET enables_C<0> LOC = N1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN2_0 +NET enables_C<1> LOC = R1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN2_1 +NET enables_C<2> LOC = M3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN2_2 +NET enables_C<3> LOC = N2 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN2_3 +NET enables_C<4> LOC = P1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN2_4 +NET enables_C<5> LOC = N3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN2_5 +NET enables_C<6> LOC = R2 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN2_6 +NET enables_C<7> LOC = P3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN2_7 +NET enables_C<8> LOC = T2 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN2_8 + +# Patch 3 +NET enables_D<0> LOC = R3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN3_0 +NET enables_D<1> LOC = T4 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN3_0 +NET enables_D<2> LOC = T3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN3_0 +NET enables_D<3> LOC = U1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN3_0 +NET enables_D<4> LOC = U3 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN3_0 +NET enables_D<5> LOC = V1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN3_0 +NET enables_D<6> LOC = V2 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN3_0 +NET enables_D<7> LOC = W1 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN3_0 +NET enables_D<8> LOC = W2 | IOSTANDARD=LVCMOS33 | SLEW = SLOW; #XEN3_0 Index: firmware/FTU/test_firmware/FTU_test6_new/ftu_definitions_test6_new.vhd =================================================================== --- firmware/FTU/test_firmware/FTU_test6_new/ftu_definitions_test6_new.vhd (revision 10057) +++ firmware/FTU/test_firmware/FTU_test6_new/ftu_definitions_test6_new.vhd (revision 10057) @@ -0,0 +1,18 @@ +library IEEE; +use IEEE.STD_LOGIC_1164.all; +use IEEE.STD_LOGIC_ARITH.ALL; +use IEEE.STD_LOGIC_UNSIGNED.ALL; +-- use IEEE.NUMERIC_STD.ALL; + +package ftu_array_types is + + type enable_array_type is array (0 to 3) of std_logic_vector(15 downto 0); + constant DEFAULT_ENABLE : enable_array_type := ("0000000111111111", --patch A + "0000000111111111", --patch B + "0000000111111111", --patch C + "0000000111111111");--patch D + + type dac_array_type is array (0 to 7) of integer range 0 to 2**12 - 1; + constant DEFAULT_DAC : dac_array_type := (500, 500, 500, 500, 0, 0, 0, 100); + +end ftu_array_types;