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. \\
+ \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. See timing diagram \ref{fig:timingtriggercase1} for details.
+ \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. See timing diagram \ref{fig:timingtriggercase2} for details.
+ \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. See timing diagram \ref{fig:timingtriggercase3} for details. \\
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]
+ \item[Case 4: LVL1 trigger without timing trigger] In case a LVL1 timing trigger is received without a preceeding timing trigger, the trigger handler invalidates this trigger with a strobe on \portname{invalid\_trg}. Even though this is not a valid trigger, the user has to acknowledge by setting \portname{trg\_release} in the normal manner. This is because the FEE could already have been triggered and the logic needs some time to recover from this situation. See timing diagram \ref{fig:timingtriggercase4} for details.
+ \item[Case 5: multiple timing triggers before LVl1 trigger] In case there is more than one timing trigger, only the first one is validated by a short pulse on \portname{timing\_trg\_valid}. When the second trigger arrives, the \portname{multiple\_trigger} signal goes high until the trigger has been released by the user. See timing diagram \ref{fig:timingtriggercase5} for details.
+ \item[Case 6: Too short timing triggers (spikes)] A short pule (currently below 40~ns) on the timing trigger input will not cause any valid- or invalid signal from the trigger handler. It only sets the \portname{spike\_detected} output to inform the attached logic about this event.
+ \item[Case 7: Too long delay between timing trigger and LVL1] During normal operation, the LVL1 information should reach the endpoint within 5~us after the timing trigger. In case this time is much bigger it is very likely that the timing trigger signal that has been seen was not the real one but noise. Therefore, the trigger handler raises the \portname{timeout\_detected} signal and sets the corresponding error information on the LVL1 channel.
\end{description}
jspc29 / daqdocu.git / commitdiff
