As soon as the frontend is able to handle the next timing trigger, the trigger is released (like the busy release in our old system) by setting the corresponding signal on the user interface along with basic error information as described in section \ref{LVL1Errorbits}.
-\subsection{Trigger-less Triggers}
+\subsection{Timing Trigger-less Triggers (TTL Trigger)}
For calibration triggers the separation into timing trigger and LVL1 trigger packet causes some difficulties: The timing trigger would start the readout process, but some time later the trigger packet arrives stating that there is no normal event but a calibration should be done instead. This then would cause the readout logic to discard the gathered data and start readout again in calibration mode.
Therefore, for calibration and similar triggers there will be no timing trigger but only a LVL1 trigger packet. To distinguish this situation from an error on the timing cable, the distinction is made based on the trigger type. Trigger types 0 to 7 are preceded by a timing trigger, types 8 to F are not. To allow for further checks, also Bit 7 of the trigger information will be set for LVL1 triggers without timing trigger. Additionally the user logic can provide some checks to assure that e.g. a normal trigger must always be preceded by a timing trigger.
\subsection{Trigger Handler}
-The LVL1 trigger handler is included in every \filename{endpoint\_hades\_full} and checks for correct timing and order on the LVL1 channel. It monitores the incoming timing trigger signal, rejects spikes and other erroneous triggers, checks timing trigger less triggers for correctness and forwards information to the FEE.
+The LVL1 trigger handler is included in every \filename{endpoint\_hades\_full} and checks for correct timing and order on the LVL1 channel. It monitors the incoming timing trigger signal, rejects spikes and other erroneous triggers, checks timing trigger-less (TTL) triggers for correctness and forwards information to the FEE.
All actions inside the FPGA and the FEE that are triggered with the external timing signal should rely on the output of this entity only. FEE which need an exact timing (with a resolution higher than the internal clock period) and therefore access to the raw timing trigger signal are the only execption from this rule. Nevertheless, the user has to make sure that the FEE is correctly working in the case that a raw timing trigger is accepted by the FEE but rejected by the LVL1 handler.
All information generated by the LVL1 handler is available on the user interface: four signals validate or invalidate incoming triggers and trigger information, two ports are used for the feedback from the FEE and several ports give additional status information about the situation on the timing trigger input.
+The input to the LVL1 handler is always interpreted in a way that allows errors on the timing trigger input but assumes that the information on the LVL1 channel is correct. To put it in simple words: "The CTS is always right, but there might be errors on the timing trigger input."
+
The checks done in the LVL1 handler include:
\begin{itemize}
\item Check the length of trigger pulse - the length is defined to be more than 100~ns. All pulses below 40~ns are rejected as spikes
\item Trigger signal is checked for right polarity. Otherwise a status bit is set and the trigger polarity can be inverted via slow control
\end{itemize}
-All possible combinations of events on the timing trigger input and the LVL1 data bus can be divided into six basic categories:
+All possible combinations of events on the timing trigger input and the LVL1 data bus can be divided into basic categories:
+\begin{description}
+ \item[Case 1: Normal Timing Trigger] On the timing input a pulse with a length of more than 100 ns is receiv, typically 2 to 5~us later a valid trigger information packet on LVL1 is received. This is announced to the user by rising \portname{trg\_data\_valid}, which shows that all trigger information (number, code, information and type) are now valid. About 60~ns after the rising edge of the timing trigger, the \portname{valid\_timing\_trigger} signal is raised for one clock cycle. This signal should be used to trigger any internal logic. The falling edge of \portname{trigger\_data\_valid} comes at least 10 ns after \portname{trg\_release} goes high.
+ \item[Case 2: Normal timing-trigger-less (TTL) trigger] A valid TTL trigger is never preceded by a timing trigger and consists of a LVL1 trigger packet with proper information only. In this case, first \portname{trg\_data\_valid} is rising. Within a few clock cycles the TTL trigger is accepted by the LVL1 handler which gives a strobe on \portname{valid\_notiming\_trg}. The end of the trigger is given by the \portname{trg\_release\_in} as described in case 1.
+ \item[Case 3: TTL trigger preceded by timing trigger] A TTL trigger is preceeded by a signal on the timing trigger input which was accepted by the trigger handler as valid. In this case, the timing trigger signal has been accepted and has been validated by setting \portname{valid\_timing\_trigger} and the FEE has started actions for a normal trigger read-out. When the TTL trigger information arrives, the trigger handler validates it with a pulse on \portname{valid\_notiming\_trg}. The signal \portname{spurious\_trigger} goes high at the same time and shows that there was an error on the timing trigger input. The trigger release is sent as in case 1 after the \portname{trg\_release} goes high. \\
+How the FEE has to react depends on its capabilities: If the data from the erroneous timing trigger can still be deleted, it should be deleted and the correct TTL trigger should be executed. In this case the user doesn't have to set any error bit on the LVL1 channel.\\
+If deleting the data is not possible any more, the TTL trigger is ignored by the logic and data from the erroneous trigger is sent instead. When the endpoint without internal data buffers is used, the user has to set the corresponding bit in the IPU error pattern during read-out of this event. The \filename{endpoint\_full\_handler} already contains the logic to set the correct information.
+
+
+ \item[Case 4: LVL1 trigger without timing trigger]
+ \item[Case 5: multiple timing triggers before LVl1 trigger] In case there is more than one timing trigger
+ \item[Case 6: Too short timing triggers (spikes)]
+ \item[Case 7: Too long delay between timing trigger and LVL1]
+
+\end{description}
+
\begin{figure}
\centering
jspc29 / daqdocu.git / commitdiff