--- /dev/null
+% Dokumentenklasse
+\documentclass{scrreprt}
+%\documentclass{book}
+
+\usepackage[pdftex]{graphicx}
+\usepackage{fancyhdr}
+% \usepackage{fontspec}
+\usepackage{times}
+\usepackage[T1]{fontenc}
+\usepackage[small,labelfont=bf]{caption}
+\usepackage{amssymb}
+\usepackage{color}
+\usepackage[super]{nth}
+% \usepackage[square,numbers]{natbib}
+\usepackage{upgreek}
+
+\newcommand{\changefont}[3]{
+\fontfamily{#1} \fontseries{#2} \fontshape{#3} \selectfont}
+
+\usepackage{multirow}
+% \usepackage{amsmath}
+% \usepackage{array}
+
+\usepackage{perpage} %the perpage package
+\MakePerPage{footnote}
+
+\usepackage{subcaption}
+
+% Eigene Trennungsregeln*
+\include{hyphenations}
+
+\renewcommand{\thefootnote}{\arabic{footnote}} %Arabic numerals, e.g., 1, 2, 3...
+% \renewcommand{\thefootnote}{\roman{footnote}} %Roman numerals (lowercase), e.g., i, ii, iii...
+% \renewcommand{\thefootnote}{\Roman{footnote}} %Roman numerals (uppercase), e.g., I, II, III...
+% \renewcommand{\thefootnote}{\alph{footnote}} %Alphabetic (lowercase), e.g., a, b, c...
+% \renewcommand{\thefootnote}{\Alph{footnote}} %Alphabetic (uppercase), e.g., A, B, C...
+% \renewcommand{\thefootnote}{\fnsymbol{footnote}} % A sequence of nine symbols (try it and see!)
+
+%-zusaetzliche Kommandos*
+%\include{command}
+
+% Dokumentenanfang
+\begin{document}
+
+% Seitennummerierung für Titel, Widmung, Danksagung, Zusammenfassung,
+% Inhaltsverzeichnis werden in römischen Zahlen gesetzt
+\pagestyle{empty}
+
+% Titelblatt
+
+\title{\Huge{CBM-MVD Readout Controller Documentation}}
+% Seitennummerierung im Hauptteil
+\author{\\B. Milanovi\'c\\}
+\maketitle
+
+%\pagenumbering{arabic}
+
+%\pagestyle{myheadings}
+\fancyhead{} % clear all header fields
+\fancyhead[LE]{\slshape \leftmark}
+\fancyhead[RO]{\slshape \rightmark}
+\fancyfoot[C]{\thepage}
+
+\pagestyle{fancy}
+
+% \changefont{cmss}{m}{n} %sans
+ \changefont{ptm}{m}{n} %times
+% \changefont{pcr}{m}{n} %courier
+% \changefont{ppl}{m}{n} %palatino
+
+% \changefont{pnc}{m}{n} %book
+
+\chapter{General Information}
+
+
+The readout of the Micro Vertex Detector (MVD) follows a general DAQ procedure.
+Starting from the lowest level in the DAQ hierarchy, the sensors provide their output using Front-End Electronics
+(FEE, see 'mvd\_docu/electronics').
+The FEE also provide the necessary resources for power distribution, programming and active operation.
+They form the basis of the readout, as they connect the sensors to the system.
+Afterwards, the data is allocated through dedicated Readout Controllers (ROCs).
+These active components are able to process the sensor data, pack them into a suitable
+network format and transmit them via an optical network for readout or postprocessing, e.g.\ by the
+First Level Event Selector (FLES).
+The readout network needs to support the large data loads without bottlenecks or deadlocks.
+
+The datarate of $30\ \rm GByte/s$ has been taken as a benchmark value for the initial FAIR experiments (see \cite{bmilan}), although
+the effective readout rate could be an order of magnitude below.
+Fig.\ \ref{Fig:MVDfull} shows a possible FAIR setup.\\
+
+\begin{figure}[bt]
+\centering
+\includegraphics[width=150mm]{img/MVDDAQ3.png}
+\caption[MVD DAQ scheme]
+{The current MVD related DAQ scheme. The MVD stations featuring M1 sensors could theoretically produce a datarate of
+up to $\sim 30\ \rm GB/s$ which needs to be handled by the readout controllers (ROCs). Additionally, all sensors have to be programmed
+via the JTAG driver boards which have to be synchronized and operate with a common, jitterless clock.
+If the entire network operates synchronously, it is possible to merge the
+ROCs and the JTAG boards together. The FEE are situated directly near the sensors and have to tolerate a large doze of radiation.
+Different types for each station are considered in order to reduce the cabling and the material budget.
+However, their geometry and the connection to the sensors is still under development.
+The Data Combiner Board (DCB) is currently not planned.
+Source: \cite{bmilan}.
+}
+\label{Fig:MVDfull}
+\end{figure}
+
+The current sensor version, MIMOSA-26, operates in the rolling shutter mode.
+The pixel matrix is hereby processed row-by-row and encoded in a specific, zero-suppressed 16-bit data format.
+The time to process the full pixel matrix, i.e. one frame, is $115.2\ \rm \upmu s$.
+Due to the fixed readout time, the sensor provides frames at a constant rate of $8.681\ \rm kHz$.
+However, the frame size varies with occupancy.
+If no hits were detected, only a small overhead of 128 bit per frame is given contributing to a data rate of $0.14\ \rm MB/s$.
+However, under full load $19.93\ \rm MB/s$ are provided.
+
+The intrinsic data format is shown in Fig.\ \ref{Fig:M26Dataformat}.
+% All data is zero-suppressed.
+The 16-bit packages are serialized on two differential output ports $\rm D0$ and $\rm D1$.
+But prior to the raw data readout, the sensor first provides some general information initiated with a Header package (see below).
+Then, the current frame number, as stored by an internal 32-bit counter, is provided on both output channels.
+The $\rm D0$ channel contains the LSB\footnote{LSB - Least Significant Bit(s)}, whereas the $\rm D1$ contains the
+MSB\footnote{MSB - Most Significant Bit(s)} of the counter.
+Afterwards, the frame datalength, i.e.\ the number of the data packages, is provided for every channel followed
+by the raw data. The datalength is always the same on both channels. This is true, even if $\rm D1$ does not contain a useful package
+in the end. In this case, the last package needs to be discarded. The dummy package can be ascertained due to a special encoding
+inside the data stream.
+After the datalength, the raw data is provided containing the row- and column addresses of the particle hits.
+The Trailer package is transmitted in the end.
+The Header- and Trailer packages are user specified unique bit patterns denoting the start and the end of a frame.
+
+
+% - Limitations: Explain 6 states per bank, 9 states per row and 1140 data packages per frame
+% (make a table of possible hits based on cluster sizes)
+\begin{figure}[bt]
+\centering
+\includegraphics[width=150mm]{img/M26Format4.png}
+\caption[MIMOSA-26 data format]
+{The intrinsic MIMOSA-26 data format. All packages are transmitted bitwise. In this example, 20 packages
+are provided, 8 of which are the sensor overhead and part of every frame (128 bit).
+The hits are encoded in the Row and Column packages. Here, 9 'states' from 3 rows are given. The datalength is 6 (per channel).
+The overflow bit is set if more than nine 'states' are found in one matrix row.
+}
+\label{Fig:M26Dataformat}
+\end{figure}
+
+Due to a charge spread in the sensing volume, it is more likely that a particle activates a whole area of neighboring pixels
+which is called a cluster.
+The rolling shutter mode allows access to this cluster only in the row-wise manner.
+Thus, if a $3\times 4$ cluster gets activated by a particle, it is read out within three consecutive cycles.
+Each cycle encodes a different part of the cluster, starting with the top-most four pixels.
+In this example, four neighboring pixels would have to be encoded into a 16-bit word.
+The naming convention suggests that such string of neighboring activated pixels in a row is denoted as a 'state'.
+MIMOSA-26 only supports 'states' with up to $4$ pixels.
+The sensor uses $18$ parallel zero-suppression blocks to encode the hits.
+Each bank is responsible for $64$ pixels of the matrix.
+
+As a result of the encoding process and the internal RAM size, the sensor is subject to some \textbf{limitations}.
+The number of possible 'states' selected in one bank of the zero-suppression circuit is limited.
+If there are more than six 'states' in a bank, which is unprobable yet not impossible, there is no possibility to perceive this.
+Furthermore, only nine 'states' per row can be acquired during a rolling shutter step.
+An overflow bit is used to mark whether this number is exceeded.
+Lastly, the number of 'states' stored during one frame is limited due to the SRAM size.
+The sensor can encode up to $1026$ 'states' per frame.
+If each particle hit would produce a cluster of three 'states' (e.g. a $3\times3$ cluster),
+this would allow the detection of $342$ particles per frame.
+In conclusion, there are \textbf{6} 'states' per zero-suppression bank, \textbf{9} 'states' per matrix row, and
+\textbf{1026} 'states' per frame.
+
+\chapter{ROC Firmware}
+\label{MVDDAQROC}
+
+The ROC firmware needs to be designed as hardware independent as possible.
+Based on the properties of latest MIMOSA generations, a generic module has been developed as a
+VHDL\footnote{VHDL = Very high speed integrated circuits Hardware Description Language} program.
+It is intended for applications on the ROC FPGA, e.g.\ on TRB2 and TRB3 boards.
+The component supports some design parameters ('generics') which need to be set according to
+table \ref{Tab:version1} in Appendix \ref{AppA}.
+After describing the operating principle and the purpose of the ROC in general,
+each of the constituting components will be discussed in detail as part of this chapter.\\
+
+\section{ROC Readout Chain}
+
+The readout of many high-performance sensors in parallel demands non-trivial DAQ routines which are covered in this section.
+The current implemention gathers the sensor data, performs an error analysis, reformats the packages
+and transmits them via TrbNet.
+In future, a cluster finding algorithm is intended to reduce the data load and increase the MVD performance.
+The ROC implementation uses the VHDL programming language, as it is intended to run on FPGAs.
+The code is thus hardware independent and
+can be loaded in any FPGA\footnote{The code contains also some FPGA dependent components, e.g.\
+FIFO buffers and PLLs which have to be recreated when changing the FPGA model. However, Virtex4 and ECP3 FPGAs of TRB boards are
+covered.}.
+
+% - Use case diagram: MIMOSA-26 (2 channels, 16bit, 80 MHz) vs. MIMOSIS (4 channels, 16bit, 800 MHz)
+
+Data from MIMOSA sensors has to be deserialized first in order to reconstruct the 16 bit sensor format, which is likely
+to form a fundamental basis of future MIMOSA chips.
+After that, frames can be extracted by searching for the Header package first. Once the Header is found,
+frame information can be gathered in subsequent packages.
+Only after that, raw data can be processed until the Trailer marks the end of the current frame (see Fig. \ref{Fig:M26Dataformat}).
+All of the deserialization and error-checking procedures are put into an VHDL module named \textbf{\textit{the readout chain}}.
+The ROC can handle several sensors at the same time simply by implementing more readout chains in parallel.
+Each readout chain is equipped with its own \textit{chain controller} and operates independently from others.
+A summarizing picture of the simplified ROC architecture is shown in Fig.\ \ref{Fig:ROC1}.
+
+% - General design aspects: parallel chains, deserialization, error detection, synchronization check (see Fig. \ref{Fig:ROC1})
+
+% build Generics to support future raw data formats
+
+\begin{figure}[bt]
+\centering
+\includegraphics[width=120mm]{img/ROC3.png}
+\caption[ROC layout]
+{The basic MVD ROC layout. Each readout chain operates independently and contains a chain controller of its own.
+}
+\label{Fig:ROC1}
+\end{figure}
+
+
+% - Describe Generics: Format, Frequency, Packet Size, Channel Number, Sensor Number (by editing these constants any MIMOSA version
+% can be read out)
+
+The ROC firmware can be configured to support different sensor capabilities, as well as different sensor numbers.
+In this chapter, only the static code based on MIMOSA-26 will be discussed.
+% - Firmware architecture and digital components from sourcecode (see Fig. \ref{Fig:ROC2})
+MIMOSA-26 provides two data channels and one clock for the ROC to
+handle\footnote{The fourth output 'MKD' which marks the start of a new frame is currently unused.}.
+Package size is 16 bit and the frame takes $115.2\ \rm \upmu s$ to complete.
+Based on the clock edge, data can be deserialized.\\
+
+Fig.\ \ref{Fig:ReadoutChain} depicts the data path through one readout chain.
+Data is first transferred into the FPGA clock domain by the \textit{input FIFO}.
+The MIMOSA-26 data with $80\ \rm MHz$ is transferred to the $100\ \rm MHz$ domain of the TRB2.
+Then, the deserialization occurs in the \textit{package generator}, which also detects incoming Header and Trailer packages.
+After that, data is written via the \textit{data handler} to the \textit{frame buffer} component,
+which is able to store several sensor frames
+and unload the readout network, if necessary.
+The \textit{formatter} can, after it receives green light from the chain controller, forward the data frame-wise to the
+TrbNet data interface.
+Parallel to this basic readout procedure, data is analyzed for errors and inconsistencies by the \textit{data checker}.
+This allows the chain controller to obtain the latest sensor status and initiate further readout steps.
+In following, individual components will be discussed in more detail.
+
+\begin{figure}[bt]
+\centering
+\includegraphics[width=150mm]{img/ReadoutChainFull3.png}
+\caption[ROC readout chain architecture]
+{The ROC readout chain components and the data path.
+}
+\label{Fig:ReadoutChain}
+\end{figure}
+
+
+\subsection{The Input Stage}
+
+The input stage of the readout chain consists of the input FIFO, the package generator and the data handler.
+All three stages are pipelined together, as presented in Fig.\ \ref{Fig:InputStage}.\\
+
+\begin{figure}[bt]
+\centering
+\includegraphics[width=150mm]{img/InputStage1.png}
+\caption[Readout chain - input stage]
+{The input stage of the readout chain. Input data stream from both sensor channels is transferred into the FPGA clock domain
+by the input FIFO, deserialized based on the Header pattern by the package generator and then stored by the data handler.
+The final output contains $2 \times 16$ bit words which are also forwarded to the data checker for a detailed analysis.
+}
+\label{Fig:InputStage}
+\end{figure}
+
+\textbf{The input FIFO} is used to transfer the databits from the sensor clock domain to the FPGA-internal clock domain.
+This procedure is referred to as clock domain crossing.
+In order to adapt the data to the new clock, an asynchronous dualport FIFO buffer
+is implemented as an IP core (async dualport FIFO).
+The FPGA clock frequency always needs to be higher than the sensor output clock.
+In case that both frequencies are the same, a jitterless clock is necessary to connect the two domains without data loss.
+
+Another important feature of the input FIFO is that it detects whether the sensor clock is still operational.
+A flip flop register is coupled to the sensor clock and changes its value with every sensor clock cycle.
+Therefore, some logic can check whether the value
+changes during the last $10$ FPGA clock cycles.
+If it does, the sensor clock is working, otherwise the sensor is either off or stopped due to errors.
+In case that the sensor clock stops ticking, an error is signalized directly to the chain controller.\\
+
+
+\textbf{The package generator} deserializes the data stream recovering the sensor package structure.
+The sensor databits are shifted into a register.
+There is one such register per sensor channel.
+The shift-register is checked and read out as one word, all bits are handled in parallel.
+Thus, it is possible to wait until the Header package arrives and start
+the packaging process from then on.
+Every subsequent 16 shifts after the Header another package is obtained, until the Trailer package arrives
+on both channels.
+Sensor resets are accounted for, as well as some basic errors.
+All decision logic is put into a Finite State Machine (FSM).
+The deserialization of one MIMOSA-26 package takes $200\ \rm ns$ corresponding to $20$ clock cycles of the TRB2 FPGA per package.
+Thus, the FPGA has enough time to process the package.
+However, this time margin is expected to decrease in future sensors versions.\\
+
+
+\textbf{The data handler} is responsible for appropriate frame buffering inside the ROC.
+MVD DAQ requires the data in a frame-wise manner.
+If due to an error or a reset one frame is incomplete
+the data handler ensures that even such Trailer-less frames are buffered correctly.
+This module has been simplyfied in order to reduce the system complexity and its sensitivity to errors.
+All data packages are counted and the total length of the frame is written at the end of the gathering process.
+Therefore, the number of packages for every frame is well known and the Header-Trailer determination can be entirely skipped, from
+here on.
+Again, the main control parts are placed into an FSM.
+Errors that signalize inappropriate sensor behavior are intercepted.
+
+
+\subsection{The Frame Buffer}
+\label{ROCFB}
+
+The data is processed and read out frame-wise.
+In order to store the data stream until the frame is complete, a large FIFO buffer is used.
+It can store several frames providing enough room for the network to process the data and prepare for further analysis steps.
+The data is stored in 32-bit packets merged from the both sensor output channels.
+In order to keep track of where the frame starts and where it ends, another FIFO buffer is used
+storing only the frame lengths.
+Thus the module uses two FIFOs, one for the data and one for the frame length.\\
+
+Current version supports up to 16 frames.
+The ROC readout speed should be faster than the sensor output rate.
+Therefore, more than two frames inside the frame buffer are unwanted and ususally signalize an error or bottleneck
+in the readout network that needs to be fixed.
+All internal errors are accounted for.
+If the buffers are running full, the readout chain will automatically stop taking further data until the problem is resolved.
+
+The module is compatible with Xilinx Virtex4 and Lattice ECP3 FPGAs.
+The corresponding architecture can be chosen by setting the apropriate design parameter ('\textit{c\_ARCHITECTURE}').
+
+
+\subsection{The Formatter}
+\label{FRWR}
+
+
+The formatter is the last readout chain module before the data reaches the network interface.
+It is responsible for apropriate frame transmission and formatting.
+The module is controlled entirely by the chain controller.
+It can be started in three modes: Normal, Empty and Null.
+The data transport to the network can have up to three stages, based on the mode.
+
+\begin{itemize}
+ \item Mode \textbf{Null} does not provide any data to the network.
+ It only handles the appropriate network handshakes and is finished.
+ This mode can be used to delete a frame from the buffer on network request.
+
+ \item Mode \textbf{Empty} provides only some basic information constituting the ROC format header shown in
+ Fig.\ \ref{Fig:DataFormat}.
+ It contains the current sensor status, some debug information and the timestamp.
+ Some necessary handshakes are exchanged as well,
+ however, no sensor data is transmitted in this mode due to the abscence of a full frame in the buffer.
+
+ \item Mode \textbf{Normal} is the standard mode of operation.
+ The formatter first acquires the frame length from the frame buffer and sets a counter.
+ Then it transmitts the ROC format header.
+ After that, data is sent from the frame buffer to the network until the counter runs down to zero.
+ Note that it is possible that even though a full frame has been transmitted, it can still be empty in the
+ sence that no particle hit was detected by the sensor.
+
+\end{itemize}
+
+Before sending the sensor data, the formatter reformats the data stream by putting some important information ahead of it
+(see Fig.\ \ref{Fig:DataFormat}). The start of the customized header is denoted by the constant 0xFFFFFFFF.
+The full schematics of the formatter is presented in Fig.\ \ref{Fig:FrameWriter}. The central part of the module
+is the large Finite State Machine (FSM) that handles all requests.
+
+
+
+\begin{figure}[bt]
+\centering
+\includegraphics[width=130mm]{img/DataFormat1.png}
+\caption[ROC data format]
+{The implemented MIMOSA-26 data format.
+The formatter simply puts some additional information in front of the original, untouched sensor data.
+All words are 32 bit wide.
+The sensor Header pattern is set to $\rm 0x5555$ and the Trailer to $\rm 0x8001$ which unambiguously separates them from the raw data.
+}
+\label{Fig:DataFormat}
+\end{figure}
+
+\begin{figure}[bt]
+\centering
+\includegraphics[width=150mm]{img/RC53.png}
+\caption[Readout chain - formatter]
+{The formatter module. It acquires frame data from the frame buffer and provides it to the readout network, after a proper
+formatting. The chain controller sets
+the mode of operation (Normal, Empty, Null).
+Mode 'Empty' writes only the format header while mode 'Null' does not write any data to the
+network interface.
+}
+\label{Fig:FrameWriter}
+\end{figure}
+
+
+\subsection{The Data Checker}
+\label{DATACHECKER}
+
+
+The data checker reviews in parallel every generated sensor package and checks its integrity.
+The raw data packages are analyzed whether they provide a valid range, e.g.\ for the row and the column address,
+and if all bits are in place.
+Hence, sensor- and transmission errors can be detected early by the ROC.
+As a result, one 32 bit status word is created per frame containing all observable error-
+and status-bits.
+Current module version is optimized for MIMOSA-26, which is also compatible to MIMOSA-28.
+Appendix \ref{AppB1} summarizes all analyzed errors.
+%Table \ref{Tab:Errors1} in
+Note that the absence of a status bit also implies an error.
+
+
+\subsection{The Chain Controller}
+\label{MVDChainController}
+
+
+The chain controller is the main component responsible for the dynamic data flow from the sensors to the DAQ system.
+It interfaces nearly all of the readout chain modules with the readout network.
+In order to support scalability, this component is integrated into every readout chain separately.
+Therefore, readout chains operate independently from each other.
+The component has to take control of the data acquisition with respect to the current network demands and the current sensor status.\\
+
+This module, as shown in Fig.\ \ref{Fig:ChainController}, comprises several different parts.
+The frame counter keeps track of how many frames are stored in the frame buffer.
+Additional logic checks whether there are two consecutive Headers without the Trailer in between, in which
+case the sensor has been reset (Reset Checker from Fig.\ \ref{Fig:ChainController}).
+If a Header takes too long, the apropriate Header timeout signal is set.
+An important part is also the timestamp generator which creates a timestamp whenever
+the Header arrives or the sensor turns inactive.
+Therefore, each frame contains the exact arrival time of its Header or the time where the sensor stopped operating.
+Lastly, the status handler gathers all relevant status and error messages from all other components and integrates them into one large
+32 bit word \textit{FRAME\_STATUS}. All status bits are summarized in Appendix \ref{AppB2}.
+If everything is fine, the status word should signalize $\rm 0xF000000F$ in hex.
+The status bits are presently only reset after the frame request signal (i.e.\ the TrbNet trigger, see below).
+If the next frame request is delayed and more than one frame processed in between, the \textit{FRAME\_STATUS} will contain
+all errors merged together for these frames. Note that this is not a problem if the frames did not have any errors,
+since then they will have the same status anyways.
+
+The current FSM implementation is compatible only with the TrbNet interface.
+Therefore it awaits a network trigger in order to start the formatter.
+The triggers are called frame requests.
+After the frame request, the chain controller decides what to send to the TrbNet: one frame, only the status
+or nothing. In case that one full frame is stored inside the frame buffer, the chain controller starts the formatter
+in 'Normal' mode (see section \ref{FRWR}). Otherwise, the formatter is started in 'Empty' mode.
+
+However, if one of the TrbNet buffers\footnote{The TrbNet Endpoint component has large buffers of its own, where
+it temporarily stores all the frames.} is running full, a certain bit inside the TrbNet will be set.
+This bit can be accessed by the chain controller during the subsequent frame request.
+If the bit is set, it means that some buffer(s) can not take an additional full frame,
+and that the MVD will produce an incomplete event.
+In such case, where full data set
+can not be provided, all ROCs stop and reset their frame buffers
+until the TrbNet can process further frames.
+This is where the formatter is started in the 'Null' mode, suppressing any data until the problem is resolved.
+As long as the bit is set, no additional frames will be taken.
+After the bit is cleared, the frame buffers will continue their operation and all ROCs
+will provide coherent frames again, as long as the sensors run synchronously.
+By resetting the frame buffers, no synchronization is lost at the cost of several missing frames.
+
+The key role of the chain controller is that it has full control over the readout chain.
+Busy signals from all active components are checked and based on the current state of the sensors, the network and
+the ROC itself, the further course of action is decided.
+
+
+\begin{figure}[bt]
+\centering
+\includegraphics[width=150mm]{img/ChainController1.png}
+\caption[Readout chain - controller]
+{The Chain Controller module, as described in text.
+}
+\label{Fig:ChainController}
+\end{figure}
+
+
+
+
+\appendix
+
+
+
+\chapter{ROC Design Constants}
+\label{AppA}
+
+
+Following list summarizes all the VHDL constants that can be used:
+
+\begin{itemize}
+ \item \textbf{Number of sensors (\textit{c\_MAPS\_QUANTITY}}) - Sets the number of parallel Readout Chains from Fig.\ \ref{Fig:ROC1}.
+ Each chain is responsible for one sensor. \textbf{Currently unused}.
+ \item \textbf{Number of data lines per sensor (\textit{c\_MAPS\_CHANNELS}}) - In future the number of output channels may change.
+ This has been accounted for in this design constant. The constant modifies the way in which the data is checked, formatted and stored.
+ \textbf{Currently unused}.
+ \item \textbf{Sensor package size (\textit{c\_MAPS\_DATASIZE}}) - Currently, 16 bit per word is used but this number might change
+ in future. The word size affects many components used for data checking and package generation. \textbf{(Currently unused)}.
+ \item \textbf{Frame readout time (\textit{c\_MAPS\_FRAMETIME}}) - This constant is used for timeout counters.
+ If the frame takes too long to finish, an error is signalized and the frame acquisition is stopped to avoid infinite loops.
+ \item \textbf{Max. Frame Packages (\textit{c\_MAPS\_DATAPACKS}}) - Sets the maximum number of packages delivered by the sensor
+ in one frame per channel (574 for MIMOSA-26). If this number is exceeded during readout, it signalizes an error and resets
+ the readout state machines.
+ \item \textbf{Header bitpattern (\textit{c\_HEADER}}) - The unique bitpattern which marks the start of a new frame,
+ as set during the sensor programming. The number is expressed per output channel in sensor word size format.
+ For MIMOSA-26, a 16 bit word 0x5555 in hex is used (or 0101 0101 0101 0101 in binary).
+ \item \textbf{Trailer bitpattern (\textit{c\_TRAILER}}) - Same as Header, only the Trailer marks the end of all the data in one frame.
+ In case of MIMOSA-26, 0x8001 in hex is used (1000 0000 0000 0001 in binary).
+ \item \textbf{Underlying FPGA architecture (\textit{c\_ARCHITECTURE}}) - Many components use IP cores which are generated during
+ the development on one particular FPGA architecture. Changing this constant enables using the architecture specific
+ IP cores, e.g. FIFO buffers. Currently only Virtex4 and ECP3 FPGA types are supported.
+\end{itemize}
+
+An example for MIMOSA-26 is given in table \ref{Tab:version1}.
+
+\begin{table}[h!]
+ \centering
+ \begin{tabular}{|c|c|}
+ \hline
+ Design Constant & Value \\
+ \hline
+ \hline
+ \textit{c\_MAPS\_QUANTITY} & unused \\
+ \textit{c\_MAPS\_CHANNELS} & unused \\
+ \textit{c\_MAPS\_DATASIZE} & 16 \\
+ \textit{c\_MAPS\_FRAMETIME} & 11520 \\
+ \textit{c\_MAPS\_DATAPACKS} & 574 \\
+ \textit{c\_HEADER} & 0x5555 \\
+ \textit{c\_TRAILER} & 0x8001 \\
+ \textit{c\_ARCHITECTURE} & \_virtex4 \\
+ \hline
+ \end{tabular}
+ \caption[ROC settings for MIMOSA-26]
+ {Following ROC settings are necessary for MIMOSA-26 sensors, as applied in MVD DAQ versions 1 and 2 (see \cite{bmilan}).}
+ \label{Tab:version1}
+\end{table}
+
+\chapter{ROC Error- and Statusbits}
+
+\section{Data Checker}
+\label{AppB1}
+
+\begin{table}[h!]
+ \centering
+ \begin{tabular}{|c|c|c|}
+ \hline
+ Bit & Type & Description \\
+ \hline
+ \hline
+ 0 & Error & Data handler error (a timeouts occurred) \\
+ 1 & Error & Received package is not a Header in IDLE state \\
+ 2 & Error & Frame number is not in the ascending order \\
+ 3 & Error & Datalengths are not same on both channels \\
+ 4 & Error & Datalength is larger than 570 \\
+ 5 & Error & Data counter is 0, but the 'state' counter is not 0 \\
+ 6 & Error & Data counter is not 0 on Trailer package \\
+ 7 & Error & Data counter turned 0 during normal package readout \\
+ 8 & Error & Number of 'states' is not between 1 and 9 \\
+ 9 & Error & Matrix row address is larger than $575$ \\
+ 10 & Error & Overflow bit is set, but less than 9 states are present \\
+ 11 & Error & Matrix column address is larger than $1151$ \\
+ 12 & Error & Row address inconsistent (row is lower than the one before) \\
+ 13 & Error & Column address inconsistent (column is lower than the one before) \\
+ 14 & Error & State counter is not 1 in the COLROW state \\
+ 15 & Error & Wrong column address on channel 2 in COLCOL state \\
+ 16 - 29 & None & Reserved \\
+ 30 & Status & Trailer detected, going back to IDLE \\
+ 31 & Status & Frame completed successfully \\
+ \hline
+ \end{tabular}
+ \caption[Errorbits - data checker]
+ {Errorbits set by the data checker. This module is explicitly created for MIMOSA-26 which has $576$ rows, $1152$ columns and
+ a maximum of 570 data packages.}
+ \label{Tab:Errors1}
+\end{table}
+
+\clearpage
+
+\section{Chain Controller}
+\label{AppB2}
+
+\begin{table}[h!]
+ \centering
+ \begin{tabular}{|c|c|c|}
+ \hline
+ Bit & Type & Description \\
+ \hline
+ \hline
+ 0 & Status & Sensor was all the time active during readout \\
+ 1 & Status & Sensor is currently active \\
+ 2 & Status & The TrbNet buffers are OK \\
+ 3 & Status & Frame complete (data checker status bit 31) \\
+ \hline
+ 4 & Error & Data handler error occurred (data checker 0) \\
+ 5 & Error & Data handler - dataready timeout error \\
+ 6 & Error & Data handler - Trailer timeout error \\
+ 7 & Error & Reset detected ($2\times$ Header and no Trailer in between) \\
+ \hline
+ 8 & Error & Received package is not a Header in IDLE state (data checker 1) \\
+ 9 & Error & Frame number is not in the ascending order (data checker 2) \\
+ 10 & Error & Datalengths are not same on both channels (data checker 3) \\
+ 11 & Error & Datalength is larger than 570 (data checker 4) \\
+ \hline
+ 12 & Error & Data counter is 0, but the 'state' counter is not 0 (data checker 5) \\
+ 13 & Error & Data counter is not 0 on Trailer package (data checker 6) \\
+ 14 & Error & Data counter turned 0 during normal package readout (data checker 7) \\
+ 15 & Error & Number of states is not between 1 and 9 (data checker 8) \\
+ \hline
+ 16 & Error & Matrix row address is larger than $575$ (data checker 9)\\
+ 17 & Error & Overflow bit is set, but less than 9 states are present (data checker 10)\\
+ 18 & Error & Matrix column address is larger than $1151$ (data checker 11)\\
+ 19 & Error & Row address inconsistent (row is lower than the one before) (data checker 12) \\
+ \hline
+ 20 & Error & Column address inconsistent (column is lower than the one before) (data checker 13) \\
+ 21 & Error & State counter is not 1 in the COLROW state (data checker 14) \\
+ 22 & Error & Wrong column address on channel 2 in COLCOL state (data checker 15) \\
+ 23 & Error & Formatter datalength error - FIFO empty\\
+ \hline
+ 24 & Error & \textit{BUFFERS\_STOP} error \\
+ 25 & Error & Header timeout error \\
+ 26 & Error & Frame counter overflow (internal error) \\
+ 27 & Error & Frame counter underflow (internal error) \\
+ \hline
+ 28 & Status & Reserved (set to 1)\\
+ 29 & Status & Reserved (set to 1)\\
+ 30 & Status & Trailer detected, going back to IDLE (data checker 30) \\
+ 31 & Status & Status is ready \\
+ \hline
+ \end{tabular}
+ \caption[Errorbits - chain controller (statusbits)]
+ {The statusbits (\textit{FRAME\_STATUS}) delivered by the chain controller. They are written together with the data in
+ the ROC format header. The word 0xF000000F marks a successful frame without errors.
+ }
+ \label{Tab:FRAMESTATUS}
+\end{table}
+
+
+%\hypersetup{colorlinks=true,urlcolor=blue}
+
+\end{document}
jspc29 / mvd_docu.git / commitdiff
