--- /dev/null
+\begin{figure}
+ \centering
+ \includegraphics[width=\textwidth]{figures/cts_structural_overview.pdf}
+ \caption[CTS Building Blocks]{CTS building blocks. The design consists of two major building blocks -- a generic network stack
+ and an extensible trigger logic}
+ \label{fig:cts_structural_overview}
+\end{figure}
+
+ In order to increase the hardware independence of the design, the CTS consists of two major
+ building blocks: The \emph{Network Logic} handles the network interfaces (which are not part of the CTS design itself)
+ and propagates event information gathered by the \emph{Trigger Logic} (see figure~\ref{fig:cts_structural_overview}).
+
+\subsection{CTS Network Logic}
+ The CTS uses two dedicated network endpoints for communications: The \emph{CTS Endpoint} is obviously needed due to
+ its unique ability to send trigger packets and coordinate the readout process. However, it lacks the support to transmit
+ arbitrary data to the storage servers, which is implemented using an ordinary \emph{FEE endpoint}.
+
+ On the TRB3, the hub and two endpoints are directly linked without additional media-interface and encapsulated into the
+ \texttt{trb\_net16\_hub\_streaming\_port\_sctrl\_cts} and are instantiated independently from the CTS in the top-entity
+ of the design.
+
+ The logic's behaviour is modelled using two FSMs, one controlling the trigger distribution and one for the readout
+ process. Both are connected by the so-called readout queue, a FIFO storing the identification of event that have been
+ triggered, but not yet read out. In case of a malfunction during read out causing a timeout this queue is likely to
+ overflow which inhibits the distribution of further trigger events.
+
+ If your CTS does not accept further events and has a full read-out queue, consider to check the
+ correct configuration of the read-out. For a in-depth discussion of the FSM states see \cite{penschuck12}.
+
+\subsubsection{Trigger Logic}
+ \begin{figure}
+ \centering
+ \includegraphics[width=\textwidth]{figures/cts_trigger_logic_overview.pdf}
+ \caption[Structural overview of trigger logic]{Structural overview of trigger logic. The trigger consists of a number
+ of freely configurable trigger modules that are ``plugged in" using the ITC channels. This gives the means for a
+ generic selection of active modules and for generic statistics features.}
+ \label{fig:cts_trigger_logic_overview}
+ \end{figure}
+
+ The trigger logic internally offers 16 channels, subsequently commonly referred to as ITCs\footnote{ %
+ \textbf Internal \textbf Trigger \textbf Channel}, to which modules are connected to. These channels in combination
+ with the memory structure discussed in chapter~\ref{sec:cts_slow_control} are the key concept to an extensible logic.
+ Together both techniques allow to design universal modules with little code overhead. Furthermore, it is possible
+ to include modules on a need-only basis, i.e.\ only the functions required by a specific setup are synthesised.
+
+ To prevent misfiring shortly after start-up, all ITC are disabled by default and have to be enabled via slow
+ control. Each ITC can be configured to be sensitive to either rising edges or high levels. If an enabled
+ channel is active, the trigger module propagates this information to the network logic. A TrbNet trigger type is
+ assigned to each ITC. The type of a given event is then derived from the lowest ITC that fired.
+
+\subsubsection{Input module}
+\label{sec:cts_bb_input_module}
+
+ \begin{figure}
+ \begin{center}
+ \includegraphics[width=0.7\textwidth]{figures/cts_trigger_input_module.pdf}
+ \caption[Block diagram of an input module]{Block diagram of an input module.
+ For each input signal an instance of an input module is
+ generated. Its main task is to cancel out noise and equalise signals
+ from different sources.}
+ \label{fig:cts_bb_trigger_logic_input_module}
+ \end{center}
+ \end{figure}
+
+ Each input signal of the trigger logic is preprocessed by an independent \emph{input module} to compensate
+ typical issues of signals from off-board electronics, such as twisted differential pairs, improper relative
+ signal runtime and electrical noise. Figure~\ref{fig:cts_bb_trigger_logic_input_module} illustrates
+ the unit's structure.
+
+ A spike rejection logic can be used to dismiss pulses up to 15 cycles in length. It is implemented using a
+ 4~bit~counter that is incremented in each cycle while the input is high and is reset if the signal becomes low. As
+ soon as the value exceeds the configurable threshold $T$, the pulse is considered valid and is propagated. This design
+ introduces a delay of $T$ cycles.
+
+ While normally all inputs should have the same spike rejection factor, the logic shifts signals relative
+ to each other when different values are used. This might lead to problems -- e.g.\ for the coincidence detection or
+ in the later data analysis.
+
+ Other sources of signal runtime are the limited speed of particles and secondary charge carriers within detectors,
+ external circuits, such as amplifiers, and the limited velocity of propagation of the signal through wires and optical
+ fibres (typically 2~m per clock cycle).
+
+ Independent of the origin, signals that are out of phase can manually be synchronised by delay lines. In an
+ input module, a delay line is built from a 15~bit shift register and a multiplexer used to select the required
+ delay.
+
+\subsubsection{Coincidence detection}
+\label{sec:cts_bb_trigger_logic_coin}
+ \begin{figure}
+ \begin{center}
+ \includegraphics[width=0.7\textwidth]{figures/cts_trigger_coin.pdf}
+ \caption{Block diagram of the coincidence detection}
+ \label{fig:cts_bb_trigger_coin}
+ \end{center}
+ \end{figure}
+
+ The coincidence detection logic is used to detect rising edges and high levels of multiple signals within an
+ adjustable window of time. It is expected that the unit is most commonly employed to cancel out statistical
+ effects, such as noise. However, in combination with a (possibly external) delay line, the module can also
+ detect a sequence of pulses.
+
+ The implementation is encapsulated into an entity which can be instantiated multiple times during
+ synthesis. The number is limited only by the amount of free ITCs. Each unit can be configured individually: One
+ bitmask selects a set of trigger inputs that have to rise within a configurable time window. For each
+ input the logic internally generates artificial pulses that start with a rising edge of the signal and last
+ for the coincidence time. Hence, as soon and long as the artificial signals of all selected inputs are
+ asserted, the first coincidence condition is fulfilled.
+
+ While the former logic monitors changes of the inputs, there is a second bitmask used for level-sensitive
+ conditions. The mask defines inputs that have to be asserted in order to propagate a edge-coincidence detected
+ by the previous stage. These signals are called inhibit inputs as they can be used to filter events based on
+ the state of an external low-active circuitry.
+ If only one of the masks is the selected, the unit can be used to monitor asserted or rising lines exclusively.
+
+\subsubsection{Pulsers}
+ Any module which leads to trigger decisions that are based on no input but the system's clock is considered a pulser. There are
+ two pulser types implemented: A \emph{random pulser} and a \emph{periodical pulser}. Both are useful to schedule events,
+ such as debug, calibration and synchronisation triggers, and allow for (stress) tests of the whole DAQ system.
+
+ A periodical pulser repeatedly asserts its output, followed by a configurable pause. The interval can be specified with
+ a resolution of 10~ns ranging from a continuously asserted signal to one event per 42.9~s. In the frequency domain, the
+ discretisation error growths with shorter intervals. The relative error, however, is less $< 10^{-3}$ for rates below 100~KHz.
+
+ The \emph{pseudorandom pulser} available in the CTS employs a 32~bit~CRC unit with a fixed data word at its input to
+ generate pseudo random numbers (PRN). If multiple instance of the pulser are synthesised with different constants. As
+ simulations suggest, the values generated are nearly uniform deviates.
+ Furthermore, the distance between two successive numbers is also distributed almost uniformly and
+ seems to be uncorrelated to their magnitude (see figure~\ref{fig:cts_bb_trigger_logic_pseudorand}).
+
+ In each clock cycle a random number is compared with a configurable threshold. If it is smaller, an event
+ is produced. Since the numbers are uniform deviates, the average duty cycle of the pulser is given
+ by the threshold divided by the maximum value possible (see figure~\ref{fig:cts_bb_trigger_logic_pseudorand}a).
+ In addition, the uniformly distributed distances prevent the clustering of events that can be observed with
+ other pseudorandom number generators, such as linear feedback shift registers.
+
+\subsubsection{External Trigger Logic}
+\label{sec:cts_bb_trigger_logic_external_logic}
+ In contrast to common trigger modules which are instantiated within the trigger logic's architecture and
+ therefore inside the CTS's component hierarchy, \emph{External Trigger Logic} lays outside -- typically on
+ the same level as the CTS's main entity. This concept is intended for modules, that required inputs different than the
+ preprocessed general purpose trigger signals, such as bindings to foreign DAQ protocols. Currently only a CBM-MBS adapter
+ is available.
+
+ Table \ref{tab:cts_external_logic} shows the dedicated external logic interface. A \genericname{EXTERNAL\_TRIGGER\_ID}
+ other than 0 (the default value) must be specified, to inform the trigger about the presence of external logic. In this
+ case the trigger logic automatically generates a trigger module memory block with the id given an two bytes payload:
+ A status and a control register managed by the CTS to used by the external logic.
+ If addition slow-control registers are required, a RegIO-hub can be used to reserve a dedicated memory area for the
+ external trigger logic.
+
+ An external module can further listen to the \texttt{TRIGGER\_BUSY\_OUT} signal to determine
+ when an event is accepted by the network logic.
+
+\begin{table}
+ \begin{tabularx}{\textwidth}{|l|p{0.2\textwidth}|L|}\hline
+ Name & Type & Description \\\hline\hline
+ \genericname{EXTERNAL\_TRIGGER\_ID} & Generic, 8~bit & Trigger Module's ID for enumeration
+ (see \ref{sec:cts_enumeration}). \\\hline
+ \signal{EXT\_TRIGGER\_IN} & Input, 1~bit & Asserted by external logic to indicate an event. It is directly
+ connected \texttt{ITC-0}, i.e. the channel with the highest priority \\\hline
+ \signal{EXT\_STATUS\_IN} & Input, 32~bit & Optional. Can be used to indicate status via slow-control.
+ The semantics have to be defined by the external module. \\\hline
+ \signal{EXT\_CONTROL\_OUT} & Output, 32-bit & Optional. Can be used to control features of the logic
+ via slow-control. The semantics have to be defined by the external module.\\\hline
+ \end{tabularx}
+ \caption{Interface of \texttt{CTS} entity to connect to external logic}
+ \label{tab:cts_external_logic}
+\end{table}
+
+\subsubsection{Latency and Jitter}
+\label{sec:cts_bb_cts_latency_and_jitter}
+ \begin{figure}
+ \begin{center}
+ \includegraphics[width=0.495\textwidth]{figures/cts_latency_input.png}\hspace{0.01\textwidth}%
+ \includegraphics[width=0.495\textwidth]{figures/cts_latency_mbs.png}
+ \caption[Latency and Jitter measurements]{Latency and jitter measurement ...
+ \textbf{(a) Left:} ... using trigger input. Yellow: Input,\\ Green: Time Reference signal,
+ Purple: Arrival at frontend (on board)
+ \textbf{(b) Right:} ... using MBS module. Aqua (blue): MBS data stream (input), Purple: Time Reference.
+ The first falling edge of the MBS data stream starts the trigger message.}
+ \label{fig:cts_bb_latency}
+ \end{center}
+ \end{figure}
+
+ Due to the CTS modular structure, the trigger latency is strongly influenced by the
+ actual trigger modules used. Figure~\ref{fig:cts_bb_latency} includes the measurements for two different channels,
+ both recorded on a TRB3:
+
+ \begin{itemize*}
+ \item The setup of the first plot directly uses an external trigger input and. Thus, the signal takes the following
+ path: In order to avoid meta-stabilities, the input is sampled using a flip-flop and then routed to an input
+ module, which takes 3 cycles for the shortest delay and spike rejection settings. The propagation delay grows
+ linearly, if either of those values is increased. The ITC handling further requires 2 cycle, followed by
+ additional 2 cycles until the time reference signal is available. In total, this
+ sums up to a delay of 80~ns. On a TRB3 board, the TrbNet stack requires another 450~ns to deliver the LVL1 packet.
+ While this number significantly influences the system's dead time, frontends with critical timing constraints typically
+ use the time reference.
+
+ \item The MBS input module is an external trigger module sampling a serial data stream of 50~Mbits$^{-1}$. It
+ propagates the trigger information as soon as the specified start-pattern is received, resulting in an overall
+ delay from the first falling edge of the start packet to the rising edge of the time reference signal of 6 clock cycles.
+ \end{itemize*}
+
+ Both latencies measured have a positive jitter of 10~ns, i.e.\ the sampling period of the CTS running at
+ 100~MHz. Thus, the design itself can be considered jitter free.
\ No newline at end of file
--- /dev/null
+ \label{sec:cts_slow_control}
+
+ The CTS's address range starts at \addr{0xa000}, and hence overlays with the address area of the HADES-CTS.
+ Just like the CTS's structure, the address space itself is separated into two major blocks,
+ one controlled by the \emph{network logic} and the other one by the \emph{trigger logic}.
+ As the former is not likely to change substantially in future developments, the first
+ block has a fixed register layout shown in table~\ref{tab:cts_register_block}.
+
+ The address block assigned to the \emph{trigger logic} has to be more flexible as extensions
+ to the trigger are very likely and encouraged by its design: Each module specifies its own -- by definition --
+ continuous address layout relative to a base address. During synthesis all individual blocks available are
+ joint together, connected only by a header as described in table~\ref{tab:cts_trg_header}. The header identifies the
+ following block by an 8~bit ID that includes the block's size and further informs the software which trigger
+ channels are connected to the module.
+
+ Thus, when initially connecting to the CTS, the software has to read the first header from the address
+ \addr{0xa100}. Even if the block's ID is unknown, the next header's address can be derived using the length
+ information included in the header word. The enumeration is completed when the last header -- indicated by a 1 in
+ its highest bit -- is read. The order in which the modules appear depends on the specific hardware description,
+ but it is not defined by any convention.
+
+ The only restriction is that every module id appears only once. If the trigger logic contains multiple
+ instances of the same module, they have to share a block, which can be indicated by the header's length information.
+ This decision reduces the amount of header words and thus speeds up the enumeration process. It further decreases
+ the code complexity of the client software.
+
+ % TODO: module header table
+ % \regtable{cts_trg_header}{Header used to identify an address block within the trigger logic's address range}{Trigger Module Header}
+
+ \begin{information}
+ The following list states block types currently used and roughly describes their structure. If you require detailed
+ information about single bits, look into the source file of the corresponding driver module placed under
+ \filename{\texttildelow /trbsoft/trb3/cts/CtsPlugins/CtsMod\textbf{\{ID\}}.pm}. These contain a (hopefully) self-explanatory register definition.
+ This way you make sure, you get the most recent definitions. To obtain a full register list, use the \cmdname{list} command
+ of the cts CLI (see section \ref{sec:cts_gs_cli}).
+ \end{information}
+
+ Currently the following IDs are used:
+
+ \begin{itemize}
+ \item \textbf{\addr{0x00} Internal Channel Masking}. This block contains one control register
+ holding two bitmasks. Each of the lower 16 bits enables one ITC (bit is 1), while the upper 2 bytes select whether
+ the channel is edge- or level sensitive. After a reset all channels are disabled to ensure that no trigger
+ is distributed before the whole network is initialised.
+
+ \item \textbf{\addr{0x01} Internal Channel Event Counter}. This block contains two 32~bit~counters for each
+ of the 16~ITCs. The first word of every pair represents the number of clocks in which the trigger channel was
+ asserted, the second one holds the number of rising edges. All counters work independently and overflow without
+ any notice. With the CTS's system clock of 100~MHz, they have to be polled at least every other 40~s to ensure that
+ no register overflowed more than once.
+
+ \item \textbf{\addr{0x10} Input Module Configuration}. Each register holds the configuration of
+ one input module as discussed in chapter~\ref{sec:cts_bb_input_module}.
+
+ \item \textbf{\addr{0x11} Input Event Counter}. This block has the same structure as \addr{0x01}, however,
+ its counters monitor the trigger inputs before they are processed by the input modules. Hence by comparing
+ both counter types, one can infer the number of events filtered by the spike rejection. Please keep in mind that
+ spike rejection and delay lines introduce a signal runtime and that there is a delay in the read access when accessing
+ multiple registers. Thus, you should not compare two absolute figures obtained from a single memory dump.
+ The later source of uncertainty does not occur when using the counters sent to the event builders.
+
+ \item \textbf{\addr{0x20} Coincidence Configuration}. Each coincidence detection module (see
+~\ref{sec:cts_bb_trigger_logic_coin}) has one configuration register. Thus, the number of registers
+ inside this block matches the number of \texttt{COIN}s.
+
+ \item \textbf{\addr{0x30} Periodical Pulser}. Each register in this block stores the low-period's length
+ of a pulser in clock cycles. $0$ results in a constant high channel.
+
+ \item \textbf{\addr{0x40} Event types}. This block contains exactly two registers that assign a
+ \emph{trigger type ID} (4~bit) to each ITC. Starting with the type of the first channel at the first
+ register's lowest nibble, each word stores 8 types.
+
+ \item \textbf{\addr{0x50} Random Pulser}. A random pulser generates irregular event patterns. Each instance
+ is configured with one control register, which holds its threshold. As discussed in chapter
+~\ref{sec:cts_bb_trigger_logic_pulsers}, for small $T$ there is a linear dependency between the average trigger rate
+ $F$ and the threshold $T$ given by $F(T) = \frac{ 100\text{~MHz} } {2^{32} - 1} \cdot T$.
+
+ \item \textbf{\addr{0x60} External logic- CBM/MBS}. This module indicates the presence of the CBM adapter
+ module. If set, the lowest bit of the control registers prevents the module from sending data to the
+ event builder. The lower 24~bit of the status register contains the timestamp of the last event seen. The
+ MSB holds the error flag.
+ \end{itemize}
+
\ No newline at end of file
jspc29 / daqdocu.git / commitdiff
