+\newpage
+
\begin{figure}
\centering
\includegraphics[width=\textwidth]{figures/cts_structural_overview.pdf}
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}.
+\newpage
+
\subsubsection{SubSubEvent Data Format}
The CTS's FEE offers two independent readout-ports (and therefore the subsubevent data consists of two blocks):
The first port is controlled by the CTS itself, while the second one may be connected to external trigger logic.
\end{center}
\end{table}
-
-
- \begin{table}[H]
+ \begin{table}
\begin{tabular}{|r|r|l|}\hline
Addr & Value & Description \\\hline\hline
\caption{Example of CTS Package. The data in the subsubevent appears in the same order as the
properties in the header word}
\label{ref:cts_subsubevent_example}
-
\end{table}
-
+
+\newpage
\subsection{Trigger Logic}
\begin{figure}
\subsubsection{Input module}
\label{sec:cts_bb_input_module}
-
\begin{figure}
\begin{center}
\includegraphics[width=0.7\textwidth]{figures/cts_trigger_input_module.pdf}
\subsubsection{Coincidence detection}
\label{sec:cts_bb_trigger_logic_coin}
- \begin{figure}
+ \begin{figure}[h]
\begin{center}
\includegraphics[width=0.7\textwidth]{figures/cts_trigger_coin.pdf}
\caption{Block diagram of the coincidence detection}
\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
+ 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}
-
+ is available. See chapter \ref{sec:cts_howto_external_trigger} for a short tutorial on how to implement a new module.
\subsubsection{Latency and Jitter}
--- /dev/null
+\newpage
+
+\subsection{HowTo Implement an External Trigger Module}
+\label{sec:cts_howto_external_trigger}
+\subsubsection{The module's interface}
+ An External Trigger Module (ETM) gives you the means to implement a high-level trigger criterion that does not require the
+ preprocessing of the general purpose trigger inputs. A typical example is a network bridge. A CTS build can include at
+ most one ETM. The module is directly linked to the trigger channel with the highest priority.
+
+ Listing \ref{lst:cts_howto_etm_instantiation} shows a minimal ETM instantiation. For a better readability, it is highly
+ recommended, that you keep the port's naming. Copy this into the top entity (\filename{trb3\_central.vhd}). Make sure
+ there is no active code to instantiate another module (e.g. comment out the CBM/MBS part). You probably need to add
+ signals, e.g. to interface with off-board electronics. The semantics of the CTS interface are very straight-forward:
+
+ \begin{itemize*}
+ \item Assert the \signal{cts\_ext\_trigger} line to indicate an event. If the CTS is idle (as indicated by a
+ non-asserted \signal{trigger\_busy\_i}), a single pulse of 1 clock cycle suffices.
+
+ \item The Read-Out Channel is directly connected to a FEE IPU Channel. See the HADES DAQ manual for more information.
+
+ \item \signal{cts\_ext\_control} offers you a 32~bit control register without any restrictions on the mapping.
+ It is connected to a synchronous output of the CTS and controlled by the trigger logic. If you need more than 4~byte,
+ just connect to the TrbNet regio bus handler (\texttt{THE\_BUS\_HANDLER}).
+
+ \item \signal{cts\_ext\_status} offers you a status register accessible via slow control. If you need more than 4~byte,
+ just connect to the TrbNet regio bus handler (\texttt{THE\_BUS\_HANDLER}).
+ \end{itemize*}
+
+\begin{lstlisting}[label=lst:cts_howto_etm_instantiation,language=VHDL,caption={Example of a minimalistic ETM instantiation.}]
+THE_ETM: <your-entity-here>
+ port map (
+ CLK => clk_100_i,
+ RESET_IN => reset_i,
+
+ -- Trigger Interface
+ TRG_SYNC_OUT => cts_ext_trigger,
+ CTS_BUSY_IN => trigger_busy_i,
+
+ -- READ-OUT Channel
+ TRIGGER_IN => cts_rdo_trg_data_valid,
+ DATA_OUT => cts_rdo_additional_data(31 downto 0),
+ WRITE_OUT => cts_rdo_additional_write(0),
+ STATUSBIT_OUT => cts_rdo_trg_status_bits_additional(31 downto 0),
+ FINISHED_OUT => cts_rdo_additional_finished(0),
+
+ -- Registers managed by the CTS
+ CONTROL_REG_IN => cts_ext_control,
+ STATUS_REG_OUT => cts_ext_status,
+
+-- Additional IOs required for your module's logic
+ );
+\end{lstlisting}
+
+\subsubsection{Registering the module}
+ no content yet
+
+
\ No newline at end of file
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
+ joint together, connected only by a header as described in table~\ref{tab:cts_trigger_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.
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$.
+ is configured with one control register, which holds its threshold $T$. 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
FPGA of a TRB3.}}
\subsection{Features}
\input{CtsFeatures}
- \subsection{Software}
- \input{CtsGettingStarted}
- \subsection{Building Blocks}
+ %\subsection{Software}
+ % \input{CtsGettingStarted}
+ %\subsection{Building Blocks}
\input{CtsBuildingBlocks}
\subsection{Slow Control Registers}
\input{CtsSlowControl}
+ \input{CtsHowtos}
\cleardoublepage
\subsection{CTS monitor}
Control and monitoring of the CTS is done using a web-server and browser interface. To start it,
-run \verb!cts\_gui!, to be found in \verb!daqtools/web!. There are few option to set the network
-port the server runs on (default: 1234) and configure the output on the command line.
-
+run \verb!./cts_gui!, to be found in \verb!daqtools/web! (must be the working directory!). There
+are few option to set the network port the server runs on (default: 1234), configure the
+output on the command line or to override the default CTS endpoint. Use the \verb!--help! parameter
+for a short overview. Before executing the script, make sure the DAQOPSERVER enviroment variable
+is set correctly.
\subsection{Event builder}
jspc29 / daqdocu.git / commitdiff