From: hadaq Date: Mon, 14 Jan 2013 18:02:46 +0000 (+0000) Subject: First part of CTS doc. Primarily a backup. INCOMPLETE X-Git-Url: https://jspc29.x-matter.uni-frankfurt.de/git/?a=commitdiff_plain;h=b838d8879fe7876a45ba4dbc0e72d8d85d6c2e98;p=daqdocu.git First part of CTS doc. Primarily a backup. INCOMPLETE --- diff --git a/trb3/CtsBuildingBlocks.tex b/trb3/CtsBuildingBlocks.tex new file mode 100755 index 0000000..69cfe58 --- /dev/null +++ b/trb3/CtsBuildingBlocks.tex @@ -0,0 +1,205 @@ +\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 diff --git a/trb3/CtsFeatures.tex b/trb3/CtsFeatures.tex new file mode 100755 index 0000000..d5fcbd7 --- /dev/null +++ b/trb3/CtsFeatures.tex @@ -0,0 +1,20 @@ +\begin{itemize*} + \item \textbf{No additional hardware requirements} as design is embedded in the central FPGA. + \item \textbf{100~MHz trigger logic frequency}. If faster logic is required, consider the dedicated CTS + add-on. + \item \textbf{Extensible and modular structure}. Both, the hardware description and the software, are designed + in a modular fashion and allow for an easy implementation of new features. A fully automated enumeration process + enables the software to determine the hardware's capabilities. + \item \textbf{Master and slave mode operation}. As master, the CTS makes the trigger decision, as slave it listings + it reacts to the trigger decision made by a foreign DAQ and distributes the information to a TrbNet subsystem. + Currently, CBM-MBS is supported. + \item \textbf{Up to 16 independent trigger modules} to implement complex behaviour. + \item \textbf{8 general purpose trigger inputs} with independent spike rejection and delay lines. + \item \textbf{4 channel TDC} to determine the trigger time with a resolution of 20~ps. + \item \textbf{Run-time configurable periodical and random pulsers modules}. The mCTS supports regular and (pseudo-)random + pulsers to produce trigger decisions with an (average) interval of 10~ns to 40~s. + \item \textbf{Run-time configurable Coincidence detection} based on the general purpose inputs. Criterion can be + edge and/or level-sensitive. + \item \textbf{Generic counters, scalers and debugging features} accessible via slow-control and embeddable into the + data stream to the event builder. +\end{itemize*} \ No newline at end of file diff --git a/trb3/CtsGettingStarted.tex b/trb3/CtsGettingStarted.tex new file mode 100755 index 0000000..0210e65 --- /dev/null +++ b/trb3/CtsGettingStarted.tex @@ -0,0 +1,13 @@ +\subsubsection{Building the design} + no content yet + +\subsubsection{\cmdname{cts} - The console interface} +\label{sec:cts_gs_cli} + no content yet + +\subsubsection{The GUI} +%\emph{For a quick getting started see sections \ref{sec:daq_startup} and \ref{sec:web_interface}.} The GUI is a web application +%and as such requires a HTTP server (also known as web server) to deliver the content to the client's web browser. A server-side +%Perl script\footnote{\filename{~/trbsoft/trb3/cts/htdocs/cts.pl}} can be invoked via the HTTP interface to investigate +%and manipulate the state of the CTS. + no content yet diff --git a/trb3/CtsSlowControl.tex b/trb3/CtsSlowControl.tex new file mode 100755 index 0000000..76eefb1 --- /dev/null +++ b/trb3/CtsSlowControl.tex @@ -0,0 +1,83 @@ + \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 diff --git a/trb3/figures/cts_latency_input.png b/trb3/figures/cts_latency_input.png new file mode 100755 index 0000000..13ccd08 Binary files /dev/null and b/trb3/figures/cts_latency_input.png differ diff --git a/trb3/figures/cts_latency_mbs.png b/trb3/figures/cts_latency_mbs.png new file mode 100755 index 0000000..5ddcf14 Binary files /dev/null and b/trb3/figures/cts_latency_mbs.png differ diff --git a/trb3/figures/cts_structural_overview.pdf b/trb3/figures/cts_structural_overview.pdf new file mode 100755 index 0000000..24ee753 Binary files /dev/null and b/trb3/figures/cts_structural_overview.pdf differ diff --git a/trb3/figures/cts_trigger_coin.pdf b/trb3/figures/cts_trigger_coin.pdf new file mode 100755 index 0000000..57dd9de Binary files /dev/null and b/trb3/figures/cts_trigger_coin.pdf differ diff --git a/trb3/figures/cts_trigger_input_module.pdf b/trb3/figures/cts_trigger_input_module.pdf new file mode 100755 index 0000000..829f5d5 Binary files /dev/null and b/trb3/figures/cts_trigger_input_module.pdf differ diff --git a/trb3/figures/cts_trigger_logic_overview.pdf b/trb3/figures/cts_trigger_logic_overview.pdf new file mode 100755 index 0000000..1b1d05e Binary files /dev/null and b/trb3/figures/cts_trigger_logic_overview.pdf differ